Here are a couple of corrections:

Programing Language:

For Apollo you can use ActionScript 3 or JavaScript. Flex is really a component layer and not really a programming language per se.

Bundled Database : This is something that may be in Apollo 1.0.

Availability : Apollo alpha is out today.

RSS, Tagging, sharing, etc... all possible in Apollo applications.

Reusable Widgets. I am not sure if you mean a UI component library (if so, yes Apollo has that), or if you can deploy widgets on the runtime (again, yes, Apollo)

Browser Plugins : both Flash and PDF plugins will work in Apollo.

Browsers Supported : We use Webkit. Its not homegrown. Also, Apollo applications run on the desktop not the browser, so I am not really sure what you mean by browsers supported.

Cross Os Achieved though : the entire runtime is cross OS. It has nothing to do with Flash and especially not Flex.

Apollo also provides an update API for applications (partially implemented in the alpha).

Those are just the items I have time to list.

More info at:

http://www.adobe.com/go/apollo

mike chambers

mesh@adobe.com

Here are some responses to your points:

Programming language: Agree Flex is not programming language but a component layer, but the comparison on the other column is Java which is a programming language + component layer. So the comparison of Dekoh supporting Java, JSP, Servlet and Apollo supporting Flex is more or less correct.

Database: Dekoh supports any database that has a JDBC driver. Dekoh bundles a database out-of-the-box which applications can use. Apollo information was taken from the FAQ on Adobe site. There is a URL reference to that on Dekoh Blog. The particular database comparison is with respect to "Apollo 1.0 will not have built in support for communicating directly with databases...." in the FAQ.

Availability: This information about release of Alpha in March was not available at the time of writing the comparison. The release information was again taken from your FAQ, which I see is updated now.

RSS, Sharing, Tagging: The comparison is for out-of-the-box features. Every application on Dekoh can use these features with little or no programming. For example you can share your application on Dekoh in one click with your private network of friends/family.

Reusable widgets: Yes these are UI widgets. If Apollo does have widgets for some of the platform services then "No" in Apollo column is wrong. An example of Dekoh widget is like the Tag Cloud widget http://www.dekoh.org/widgets/tagcloud/tagcloud_xml_example.html Dekoh applications can use tagging facility offered by the platform. To integrate this feature into the application developers dont need to write their own UI component. They can just plug in the UI Tag Cloud widget.

Browsers Supported: This item refers to - if applications written using the platform run inside browsers like IE, Firefox, Safari. Reason, Apollo column refers as "homegrown" because Apollo FAQ says "You can download Adobe's changes to WebKit for Apollo...", so guessed there are some Apollo specific changes made to Webkit.

Plugins supported: Similar to the point above. You can integrate any existing browser plugins or write applications integrating Firefox, IE, browser plugins in Dekoh.

Cross OS achieved: I am not sure what you mean by entire runtime is cross-os. I am under the impression that there will be OS specific downloads of Apollo platform (Whereas Dekoh is same binary on all OS platforms because it is Java based). This point in the comparison chart is actually referring to applications written on the platform. I guess this is what you mean by cross-os runtime. Applications written will run on all platforms where Apollo runs, application developers need not worry about compatibility. It is the same point with Dekoh.

Vijay
Dekoh

Ironically I’m trying to raise some $$$ to $ponsor a World Tour whereby I visit a lot of the talented Artists & Photographers on Flickr* Showcasing the Web2.0 Social Networking & User-generated content of Photos, Videos, Music Podcasts, iTV, Books, Art & much more* A New Widget encompassing all these elements would be produced*

I'm excited to take a look at Both!!

Cheers! Billy ;))

Some of the Apollo demos have been re-worked for Web2os to show the differences - the version of Maptacular pulls in data directly from Address Book or Outlook for example.

The offline Google Calendar example also shows a different approach - keep the same Ajax code in the browser, but serve offline requests from the local proxy, with its embedded javascript environment and sqlite database.

Great to see all the activity on web/desktop/offline apps!

Rhys

How about R/WW planning a comprehensive critical analysis of Morfik, Apollo, Dekoh, or any other developments towards web on the desktop, for later on this year?

That doesn't make sense. Apollo supports JavaScript, HTML, ActionScript 3, MXML, haXe, and the Flex framework.

Apollo information was taken from the FAQ on Adobe site. There is a URL reference to that on Dekoh Blog. The particular database comparison is with respect to "Apollo 1.0 will not have built in support for communicating directly with databases...." in the FAQ

I think thats a good thing about the Apollo project so far, they have been quick to get developer feedback in the loop very early in the process, and integrate it.

Reusable widgets: An example of Dekoh widget is like the Tag Cloud widget Dekoh applications can use tagging facility offered by the platform

Apollo allows these from community and open source projects, not necessarily bundled into the platform. I would think adding widgets like this to the platform is overkill. Sure Tag clouds are popular right now, but seems like something I would add to my specific app if I needed it.

Browsers Supported: This item refers to - if applications written using the platform run inside browsers like IE, Firefox, Safari

Okay, this means either I'm stuck worrying about cross-browser compatibility, or I need to make sure my end-user has the right browser. Is this a benefit?

I am not sure what you mean by entire runtime is cross-os. I am under the impression that there will be OS specific downloads of Apollo platform (Whereas Dekoh is same binary on all OS platforms because it is Java based)

Isn't this a benefit? Adobe can make sure the experience is right on each OS, while us developers can focus on the app. Using the exact same binary on each platform just seems like it would add inflexibility. (Even Java-based GUI apps on Mac use separate binaries, to be more Mac-like)

In the case of Apollo and Dekoh, both bring the power of web and its programming models to otherwise conventional desktop applications. Apps that run on the desktop, for the desktop user. Just that it is written using existing web programming languages, and can easily access resources on the web. Additionally, Dekoh does also bring the "virtual desktop" into the mix- the apps running on dekoh can be accessed by the user from anywhere on the net (if permissions set accordingly).

One other aspect of Dekoh is that unlike Apollo, its installation is automatic. The user need not explicitly do anything (that is why it has the zero-maintanance advantage). And being pure Java based, there will be no platform dependancies or variations (atleast surely not for leading desktop environments today- Windows, Linux and Macs). So not much of an advantage from OS specific ports.

1. Flex comparison was with server side Java technologies. Client side UI support is separately listed in the comparison.

2. "Adding widgets is a overkill". Dekoh platform provides several web 2.0 like functinality like tagging, sharing, commenting for desktop applications. The widgets make it easy to use these features in applications. On my blog http://pullur.wordpress.com/ there is a screencast of photo application you can see how this application uses tagging and makes use of the tag cloud widget without coding. Again, UI widgets to easily leverage platform features reduces lot of work for developers.

3. "Stuck worrying about cross browser compatibility" - If all web applications end users are using runs on the browser...why should web-desktop integrated applications run outside the browser? Cross browser compatibility is overcome by several AJAX toolkits or using Flash in applications. Both run inside the browsers. Accessing applications in the same browser users are used to accessing web applications is a benefit or not is a point of view. I am sure you can argue both ways.

4. "cross OS". I do not understand what you mean by "same binary would add inflexibility". Dekoh runtime is Java and because Java is compatible on multiple platforms we enjoy the benefit of using same binary. Java offers extensive OS neutral API to access system services. Dekoh applications can make use of these and still be cross-os. Not sure Apollo offers as extensive API as Java does on as many platforms.

Vijay
Dekoh

Sharing is the killer app and sharing from the desktop is harder than it needs to be. I am happy to see that both platforms are trying to address this but the challenge for both will be convincing developers and then end-users to install yet more desktop applications. There has to be a compelling value proposition - Mashing up existing web services in a non-browser environment is not enough.

We are taking a slightly different approach with our own p2web platform (CloudStack) where rather than creating new desktop apps, we are working to "webify" existing desktop apps and bring together the best of both worlds - the ubiquity of the web with the efficieny of the desktop (through P2P).

1. Flex comparison was with server side Java technologies. Client side UI support is separately listed in the comparison.

This is where a lot of the confusion seems to be coming from. Apollo works great with Java, JSP, Servlets and all of that. Apollo is a client technology. (Just like XUL, Cocoa, and WPF) It doesn't attempt to replicate the whole server eco-system right on your desktop. It can communicate with the server-side, do smart caching and syncing.

Unlike Dekoh, which looks like it puts a full-blown server right on your machine. (http://www.dekoh.org/wiki/view/DekohArchitectureAndConstituents)
Don't know if I would want that.

2. "Adding widgets is a overkill". Dekoh platform provides several web 2.0 like functinality like tagging, sharing, commenting for desktop applications.

Sorry, that does sound kinda cool. Just didn't know how cross-cutting it is.

3. "Stuck worrying about cross browser compatibility" - If all web applications end users are using runs on the browser...why should web-desktop integrated applications run outside the browser?

This is one of the most interesting aspects of Apollo, being able to shed the browser chrome, provide a better experience focused on the task on hand, and integrate better with the desktop.

4. "cross OS". I do not understand what you mean by "same binary would add inflexibility". Dekoh runtime is Java and because Java is compatible on multiple platforms we enjoy the benefit of using same binary.

So this is also another point of confusion. Where is the value for application developers vs. the runtime developers.

For application developers, they just need to worry about developing for Apollo and it will work cross-platform. They also get an install and OS experience for their app that matches the end users operating system. (An app bundle for Mac, that can be dragged to the Dock. Or a desktop shortcut, and install directory in Program Files on Windows.) Application developers get the value, where it counts.

For the runtime developers, Adobe, they get to do all the grunt work, to make sure the experience is the best it can be for the different operating systems.

So the value isn't reusing the same binary or package for the runtime, the value is reusing the same package for the applications built on top of the runtime.

1. Applications have 2 components logic (aka business logic in web paradigm) and UI. In Dekoh logic and UI can be cleanly separated and developers have choice of technologies to choose from for both. "full-blown server" including all constituents listed in the architecture is less than 5mb, if size was your concern. It is one-click install and zero administration. Serves only browsers connecting from localhost.

3. I agree with you that Apollo and Dekoh are 2 different approaches for writing Desktop-Web integrated applications. Dekoh applications UI is typically rendered inside user's favorite browser and Apollo applications outside. As for better integration with desktop, both can do the same (if you are referring to run as service, desktop icon, add remove programs, system tray...). Additionally it is possible to have single desktop icon for Dekoh which opens the personal desktop portal from where all other dekoh desktop applications can be invoked from. Less clutter on users desktop icons and OS short-cut menu.

4. As I said in my original response applications written on both Apollo and Dekoh run on all platforms. You can use exact same application package and run it on dekoh on all platforms. Dekoh leverages the decade long tested compatibility of Java on many platforms. For example Dekoh (and applications) run on Linux and Solaris. You can argue this is a small user base, but then developers get the advantage of true cross-os benefits.

Vijay
Dekoh

Some of the other features are unique, but I've always had a resistance to comparison charts with lots of ticks on one-side and nothing missing - you get the feeling the comparison has only been made in the winning areas, not that a product is 100% better.

>I would still love to see a writeup on why to use these >platforms over XUL :)
>Feel same,I would still love to see a writeup on why to use >these platforms over XUL too.

Turn the question round and ask why use XUL over Apollo or Dekoh, if you're not bothered by the open / proprietary debate, but just the technological one?

The key thing for Adobe is that they're taking their development community (used to working with Flash and JavaScript) and letting them use their existing skills on the desktop. Learning XUL would be a step outside the box. And I suspect - from the XUL apps I've seen - it's still easier to deliver a flashy UI in Flex than XUL.

Me - I still want to see the arguement as to why you'd use any of these platforms to produce a cross-platform / cross-OS application. Or more specifically - why is a Mac user going to choose a cross-platform application over a native one? Cross-platform all too frequently is about solving a problem for developers not users.

I think the "RSS support" is litle cryptic. Here is the explanation of RSS on Dekoh:

Dekoh Desktop comes with a RSS widget that consumes RSS feeds and can be configured to display the feeds in the browsers inside any app you build on Dekoh. For example, you can have a “What’s New’ page on your personal Photo
application that gives you a news update when a friend comments on your collection.

Dekoh Desktop also has a easy-to-use feed generation API that feeds out on ATOM RSS formats. The API is tested and works across all versions and variations of ATOM and RSS.

We thought that is very useful and handy for developers than build RSS reader on their own in applications. On any "Platform" most things are possible to do for a good programmer. The comparison is only for out-of-the-box features.

Vijay
Dekoh

With Dekoh, Is it possible to do offline work and sync automatically when connected? And Will it even work if my client application is written in Java/Flash?

In other words, Can you do the following demo using Dekho?
http://www.youtube.com/watch?v=RurAaFUjpvE

Yes you can do offline and sync. One of the applications that will be available at the time of public alpha is Google calendar offline. You can create calendar events on the desktop, even when you are offline. It will sync with google when you connect again. you can record personal voice alerts for google calendar events that will play on your desktop. Similarly, it is possible to write an application for ebay using ebay API. We are not attempting to write ebay app, unless ebay is interested :).

Vijay
Dekoh

Apollo looks to have the edge but it has one massive flaw to me and that is you need to pay for a decent toolset. Sure the SDK is free and you don't need the Flex ide but many developers including myself like a good ide. Having already invested in Visual Studio 2005 and Flash Pro and PS its a stretch to buy a new tool.

Their models is very invasive and annoying, look at what they have done with Acrobat as well as with Flash.
Flash-Lite is another totally closed mess up they have pushed into mobile space, now this .. I would never develop on it.

Perhaps I am missing the point, but why would I use something like this (a webos "platform"), that requires special run-times or plugins.. when I could just as easily write a full fledged java desktop application with Swing (or some other windows api)? I can just as easily access web services using that technique, and I can certainly create a GUI just as easily.

Good news:

o you can work entirely in JavaScript/HTML:
http://labs.adobe.com/wiki/index.php/Apollo:developerfaq#Can_I_use_just_HTML_and_JavaScript_to_build_an_Apollo_Application.3F

o or you can use any modern SWF-producing tool, including:
http://osflash.org/projects

o or you can create MXML any way you like and compile it to SWF, at no cost:
http://www.adobe.com/products/flex/sdk/

o and the tools to turn this into a standalone application on Mac and Win desktops costs nothing, either:
http://labs.adobe.com/wiki/index.php/Apollo:developerfaq#Is_Apollo_free_.28as_in_beer.29.3F

Your judgment of "a decent toolset" may influence your final investment decisions of course, but there are many effective ways to use Adobe's Apollo work, without paying a cent.

jd/adobe

Dekoh looks to have an edge...

- all familiar languages and scripting, that people have been using for years to build web applications - Java, JSP, Servlet, Javascript, JSON, DHTML, CSS, Ajax, Flash, etc.

- developers can continue to use the same tools they were already using, including open-source IDE such as Eclipse

- no new API to learn for common things like accessing a file or database

- open source

- Dekoh Network, the sharing and web2.0 platform

many more.

Again, Apollo works great with Java, JSP, and Servlet technologies, where they normally are found, on the server. (Servlet even has part of the word server in it) A server running in a server environment, not on a user's desktop.

And you can write Apollo applications using the other technologies you mention: Javascript, JSON, DHTML, CSS, Ajax, Flash, etc.

- developers can continue to use the same tools they were already using, including open-source IDE such as Eclipse

What tools were developers already using for Flash, Flex, JavaScript, and HTML development? They can still use those. (Which include open source editors)

- no new API to learn for common things like accessing a file or database

Again, this is what is new and innovative with Apollo. Allowing developers who develop with traditional client-side technologies, to do these new types of things. So if an API has never existed in a language before, like JavaScript or ActionScript, of course it is new.

- open source

Yes the core runtime is not open source, but that is a debate unto itself of the value. Flash Player is tremendously successful and an awesome platform to target, and it is not open source. Besides, many of the projects surrounding the platform are open source:
http://code.google.com/p/flexlib/

Including one that even bridges..... Java! to Apollo:
http://artemis.effectiveui.com/

- Dekoh Network, the sharing and web2.0 platform

Apollo works with existing sharing and web2.0 platforms, and any that come along later. As all of it's components are originally web-geared anyways.

many more

?

When you build desktop applications using Swing/XUL/WinAPI, you can access web services. But the application will not be accessible over the web. It is a one way street in most cases (thanks to NATing and firewalls).

With dekoh you can share the applications that are running on your desktop over the web. When you share an application to your buddy, they can access the application from http://yourdekohid.dekoh.net/appname. Your buddies do not need to install anything. All they need is a good old browser.

Also, your application could expose web services (SOAP/REST) which you can then share with your buddies. Your buddy could then access the web service from any platform Dekoh Desktop or otherwise.

1) Ever since Sun and Microsoft fell out, Java on Windows IS a special run-time / plug-in.
2) The quality of typical Java application GUI compared to what people are doing using Flex/Flash, suggests to me that creating a high quality GUI in Java is obviously not done just as easily. Either that, or Java developers lack the skills or motivation to create them.
3) I suspect you've not even looked at how easy it is to create a decent quality GUI in Flex.

Are you actually trying to sell me? If so, then I'd like to talk with you first about some superannuity policies I have, and then of course I'm also throwing a Tupperware party next week, and..... ;-)

jd/adobe

PS: Oh, I see, I clicked through to his URL, and Jay's another Dekoh guy, semi-disclosed. I like their enthusiasm for what they do, but....

But guys, your doing a gr8 job....congrats to vijay, jay and all ur team ...infact proud to say iam from hyd too.

Runs on any platform/OS and in any browser.
The calculator source tells the tale, http://www.naltabyte.se/widgets/calculator.xml