Switching from WebKit to CEF and removing server-side languages support

[pkorzeniewski]

I have a question to people who digged through the Titanium Desktop code - in your opinion, how hard would it be to switch from WebKit to CEF and remove server-side languages support (and therefore Kroll)?

Why I am asking this - these two steps would make future developement of Titanium Desktop much, much easier.

[fairwinds]

Hi. Certainly there has been discussion about this. The object bridge and the language support is a key differentiating factor in TideSDK vs anything in future that may be competitive. Further this lang support is an option for an app developer to use or not use. The fact that it is supported, opens are range of possibilities for complex apps that I have been taking advantage of. I currently have apps in development with multiple running processes and interaction in python for example.

Where the rubber hits the road is development. I am committed to this code base provided we can move forward with legal clarity. CEF integration is something Josh has been working on as an experiment. You can already integrate nodejs in an app. I have been using it this way for months. Nonetheless, an experimentation would be done in a branch and the reviewed by the team. We also have a user base to consider and differentiating characteristics to other projects for the desktop to consider.

We have yet to fully solidify our support from Appc to determine the future but encourage your involvement if you have an interest. We are laying some foundations to help orient developers with the code and have a scheduled Q&A together with Marshall Culpepper, original developer of Titanium Desktop Friday June 15 at 3PM EDT / 1PM PDT on #tidesdk on freenode. We will be consulting on the architecture, potential, and priorities for TideSDK. Please drop in for the Q&A if you are interested.

[Hugo Rodrigues]

hello fairwinds,

I'm glad you take the project and are moving forward. Wish you best luck.

support is a key differentiating factor in TideSDK vs anything in future that may be competitive

Thats true, but the implementation of mixing javascript/html + php/python/ruby is is just wrong.
It's crappy and bloated. I guess that's why the appc drop the project: It's unmaintainable and unreliable and very hard to build cross platform.

Tidesk should only focus on UI/webkit/CEF, and BASIC OS interaction (windows, toolbars, and external programs). If you can run external files, and those file can be py/rb/php why do you need that build in tidesk? Why can't those dependencies be standalone? (check nodejs example)

Best Regards,
HR

[pkorzeniewski]

I know that server-side languages support is an unique feature, and it surely can come in handy, but I think we can all agree that it requires much more work to maintain (actually it's another project to work on). My point is that it would be great to have a "lightweight" version of TiDesk, basically CEF implementation + OS integration and maybe plugins support. Sure, it's not a big deal to create new project based entirely on CEF, but TiDesk already have a great OS integration so it would be better to use it, rather than create from scratch.

[Russell Leggett]

Hi all, just figured I'd jump in here. I was helping to explore alternatives a while back including CEF. I posted a little summary as to why I had basically given up in that area, but I'll summarize.

1. Moving over to CEF would require a major move of all the native code stuff to integrate there instead of how it is currently working. Hopefully this wouldn't be too difficult, but it would definitely be an undertaking.

2. Our thought was trying to pair node and CEF together, but there are a lot of tricky details with this - merging the event loop/UI thread vs message passing to a node instance. How do you install an app with all of the npm packages, what about native code, etc.

3. Neither CEF or Node stand a very good chance of getting into the mac app store anytime soon. I think the same will be true about Windows 8.

4. It doesn't help all of the people relying on how TiDesktop works now.

The reason I stopped participating in this project really, is that I don't have any legacy TiDesktop project I need to keep working, and basically I don't think there is a good evolution forward into the app store future. It would basically have to become phonegap, and that's already moving (slowly) to add support for desktop.

I think it is extremely worthwhile to keep pushing ahead for those people who could benefit from the way TiDesktop works now - whether that's because you have an existing project, or if it would really fit your needs on a new project. That said, I think the approach has a limited lifespan.

In case anyone cares, this is my prediction for the future:

1. Mozilla is going to keep banging on bringing web standards up to what would be needed to compete with desktop apps. Their work on B2G is laying the groundwork for figuring out APIs, and they're adding it back to Firefox on desktop/mobile. They're creating their own app store, but they're trying to pioneer an cross-platform cross-app store standard. While I don't think it will all happen exactly as they are doing it now, eventually I think something along these lines will come to fruition.

2. Until a standard happens and actually implemented across the board, phonegap/cordova will do what it does best and fill the gap. They will place a high degree of importance on being app store compatible, and really be the best way to share code between app stores, platforms, desktop, and mobile. If you want to blaze a new trail, supporting that is your best bet for the future IMO.

All that said, I would like to reiterate again that there is a need that TideSDK could fill right now, but its not going to be through a change to CEF or using Node. If you take Tide out of the picture, the only real option would be Air, and that's just not an option for some people. Phonegap stuff for desktop is not very far along, and what Mozilla is working is definitely further off. TiDesktop basically works right now, and with some updates to Webkit, can really be very useful, even for those not interested using other languages.

- Russ

[fairwinds]

Hi Hugo. Kroll support is currently isolated. Keep in mind we are inheriting a code base and that any changes we make will be incremental. The multi-language support provides capabilities for libs and embedded binaries within the app to enable more complex apps to be constructed using mature libs not available within nodejs. I think there are wide variety of opinions on where it ought to go but it really comes down to some experimentation in branches and evolving the code base gradually. What we do know is that we desire further exploration of CEF and a tighter nodejs integration if possible. This must be done in a context that ensures the sandboxing requirements and constraints for entry to the app are also adhered to for continued access to app stores.

David  

On Friday, June 15, 2012 9:45:55 AM UTC-3, pkorzeniewski wrote:

[BigMacAttack]

I definitely agree with Russell here.

I strongly feel that TideSDK should not go the route of using its own proprietary web framework. It bloats the distribution and installation size, requires development and support of the framework, and is just plain unnecessary when there are web frameworks that ship with each major desktop OS. It is only with mass adoption of a tool that distributing a framework doesn't really matter, but not even Silverlight, AIR, .NET, etc. have what I would consider mass adoption. So chances are your app may be the only app a user has installed on their system that requires a proprietary TideSDK framework. So why do it?

Here would be my suggestion instead. Go the phonegap route and just embed a webview from an existing installed web framework and build off of that. This would keep most app redistributables under 5MB!

Mac OS X
Webkit Framework

This one's easy. All distributions of Mac OS X since 10.3 ship with the Webkit Framework.
Here are some opens ounce projects already leveraging the framework and could lay the foundation for a tidesdk Mac version: 
-Fluidium(https://github.com/mital/fluidium)/Fluid App(http://fluidapp.com/)
-Phonegap-mac(https://github.com/shazron/phonegap-mac) 

Linux

XULRunner
This one would be pretty straight forward as well. Ubuntu (and Linux Mint), arguably the most used end-user distributions of Linux worldwide, have been shipping the XULRunner runtime with their OS for several years now. And for the distributions that don't ship with XULRunner, installation is very straight forward for most *nix folk (sudo apt-get install xulrunner).

Windows
"Trident Shell" - IE Framework/Google Chrome Frame/XUL Runner 
Dealing with Windows is a little harder and certainly deserves further discussion, but I think there are good ways of handling this OS without having to distribute a web framework. Windows Forms applications allow you to embed a web view into the app that use IE. Check out these examples: 
-http://www.c-sharpcorner.com/uploadfile/mahesh/webbrowser-control-in-C-Sharp-and-windows-forms/ 
-http://www.menubox.com/

Using IE is certainly not ideal I know, but there are workarounds. TideSDK could search to see if either Chrome or Firefox is already installed on the target OS and use those frameworks instead. "Google Chrome Frame"(https://developers.google.com/chrome/chrome-frame/) does this quite painlessly for IE 6-9 users as a simply browser plugin and perhaps something similar exists (or could be built) for using an installed Firefox framework. And it could degrade nicely by using the developer's preferred framework and then only using IE as a backup.

In addition, Windows 8 plans on shipping with a great web platform called Windows Runtime (WinRT). It should also be noted that if a developer plans on creating any app for Windows 8 on ARM, that WinRT is required and metro-style apps distribution is a requirement!

Well if you made it this far and I haven't lost you, here is another idea. Why not join development efforts with Apache Cordova and the PhoneGap team? Getting acceptance and dev support from them in the beginning might help to spread adoption of a phonegap-desktop framework and perhaps even become apart of the powerful PhoneGap:Build tool.

[fairwinds]

At the heart, we currently have builds and a functional product and invite you to participate in TideSDK's development. The intent in the short term is simply to get the components and libs updated and this will take some time. Meanwhile we are releasing a usable product for our users. As this is being done, with consultation and ideas, we will map a future to ensure we remain in the app store markets. The sandboxing for AppStore compliance is one of our highest priorities.

We see the future changing. That part is certain, but if we are selective about where to invest our efforts, we should be in good shape for the foreseeable future. In addition, much like Appc has on the mobile side with native capabilities, TideSDK may be able to grow some API additions. We have a unique product and a low barrier for developers to use, an api that is familiar from the mobile side, and language capabilities that differentiate the product. There are all good things. Lastly, anything major must begin in an experimental branch so that if we have folks with an interest in bringing forward challenging ideas, it must be spelled in code so that we can evaluate it impact and advantages.

David

[fairwinds]

Hi Russell. We have talked about many things together. My plan in short term for code base is v simple. Get a release candidate out as soon our builds and tests are good, bring underlying libs up to date, possibly reduce lang support to python. Beyond that we look to the sandbox that Apple requires as next highest priority and it will require some thought. We talked today with Marshall Culpepper, the original architect of TiDesktop at length. This dialog was excellent. He is currently working for Mozilla on B2G. Together we believe it is a worthy project and has a good future. Josh has been doing some work with CEF and hope to touch base soon on that aspect. We are on #tidesdk. Drop by at any time.

Regards

David

[Micheal Cottingham]

Hm. The reason I chose Titanium Desktop over jRuby or Java or jython was that I could write the UI in HTML/CSS/JavaScript and the backend in a language I was comfortable with such as PHP or Ruby. But if that's going to disappear, my reasons for staying are diminishing.

Why would those be removed? I admit I haven't been keeping up with IRC or the wiki, but maybe some clarity? What are the reasons the language support is being removed? What would be done in its place to get that processing capability? I can write a UI in Java and pass off the rest to Python or something, what's the difference here? What is going to set TideSDK apart from Qt or Java?

[fairwinds]

Hi Michael. The kroll bridge and language support will stay. Please don't be worried. We had some lengthy discussion with the original developer of Titanium Desktop Marshall Culpepper on Friday. There has been discussion on reducing the language support to python since early in the year. The additional PHP and Ruby adds a burden for maintenance. Marshall raised this in the session as a possible means to reduce the work load involved in maintaining the SDK. If this were to materialize, leaving python is a reasonable choice since it is clear, expressive, mature and universal glue language that is well supported with libs for every conceivable need.

No firm decision will be made on this until we look at upgrades to the languages to bring in step with the current versions, we will be in a better position to assess the volume of work involved after we have performed this. I am keenly aware there are folks that user the framework for its existing support have no intention of harming our users. Any major changes like this will be well considered before we do anything. Can you advise what support you are using, btw?

David 

[Micheal Cottingham]

ah. I see.

Well, most of my time with Titanium Desktop was learning the APIs and stuff, so I bounced between PHP and Python. I had a few projects in mind that I wanted to build, but the last couple of years had seen diminishing support from Appcelerator for the desktop, so I lost interest in using their products. However, I'm learning Ruby for projects at work, so adding it in to my personal projects with TideSDK would be been nice. I understand the reasoning behind going with just Python though.