Archive for Apollo

My interview at

Rajesh Setty has published my interview with him Behind the scenes – Dekoh; Interview with Vijay Pullur. I have talked about several topics like our history, why Dekoh?, how is it different from Adobe Apollo and Google gears, enterprise and SaaS ISV use cases for Dekoh etc. Thanks Rajesh for interviewing me and publishing it.


Comments (1)

Google gears – offline web applications

Google has today announced Google gears. It allows web applications to work offline. Google gears is a browser extension that can be downloaded and installed. It exposes Javascript classes which can be invoked by web applications to provide offline functionality.

While it appears cool at first look, it needs to be analyzed in detail. Here are some initial questions that needs to be answered:

1. Does the user have control over deciding which applications to make offline? How much data should be available offline?

2. Does the offline functionality run in-process (in the browser)? If it runs in-process is there a chance of browser bloating up in memory due to offline caching or run slow?

3. What about security? Is it possible for a rogue application to cache and use background threads to connect to their site just because the user visited the website and the Javascript accessing Google gears got loaded?  

4. Does Google gear intercept all HTTP requests going out of the browser? If I am offline and just type how does it capture this request and present me with offline content?

5. It appears the offline functionality is going to work only for pure Javascript applications. How does it work when application has other tiers like Java, PHP, Ruby….?

6. Writing applications to handle connection status and gracefully transition is going to be a programming  challenge (nightmare).

Interesting to note Adobe Apollo support for Google gears (or viceversa). “Kevin Lynch, senior vice president and chief software architect at Adobe, said his company will join Google in the effort to develop a standard cross-platform, cross-browser local storage capability. The Gears API will be available in Adobe’s Apollo tool that enables Web applications to run on the desktop, he added.”. I thought they did not accept this – Adobe Apollo – On A Collision Course With Web Browsers 🙂

Technorati Tags: , ,

Comments (2)

Examples of 2 RIA approaches

Here are 2 examples of Rich Internet Applications:

eBay San Dimas Project: Provides offline functionality for eBay. Can create desktop alerts for eBay bids. Written using Adobe Apollo platform.

Dekoh Calendar: Is a desktop counterpart to Google Calendar. Allows creating desktop reminders and audio alerts for Google calendar events. Works offline and syncs events next time connected. Written using Dekoh platform.

Functionality offered by both the above is similar. Both applications can be accessed in an airplane (no internet connection) The big difference is in the way user interface is rendered. eBay application is run like a native desktop application outside the browser. Dekoh calendar is accessed from the browser.

Technorati Tags: , , , ,

Submit to digg Technorati Yahoo My Web

Comments (3)

RIA – is it “Rich Interface Application”?

Stephen O’Grady of Redmonk has written this good post Too Rich For My Taste: The RIA Q&A questioning the value of Rich Internet Applications to end users. Some of the observations are  very accurate. Two of them related to Internet Applications are very important:

1. We spend more time using browser based applications  than thick-client desktop applications (exceptions are developers). Browsers are universal client program people are comfortable using.

2. End users are happy using current web interfaces. In the recent years AJAX has made it even better. There is no real need for making application interfaces richer. Don’t fix what is not broken.

The big vendors of RIA, Adobe (Apollo), Microsoft (Siliverlight) and Sun (JavaFX) seem to be making excessive emphasis on richness of interface and pushing their technologies forgetting the above crucial points. The richness of interface is highlighted so much in the demos and talked so much about in their marketing that RIA can be interpreted as “Rich Interface Applications”.

Is there a reason why richness of interface is played up, although RIAs are meant to provide richness in 3 dimensions?

I think the 3 big vendors have a problem with “Internet Applications” part of RIA definition. Internet Applications imply using the browser as the client. Adobe Apollo and Sun’s JavaFX do not run inside the browser, so point #1 above is not in favor of them. If it is not about writing super cool UI Silverlight has no place, so point #2 is not in favor of Microsoft Silverlight.

Does this mean RIA has no role? Should you be a skeptic the way Stephen is?

I think RIA has a big role to play connecting the web to the user. RIA provides a way for web to interact with the user in more ways than current request-response model.

Technorati Tags: , , , ,

Submit to digg Technorati Yahoo My Web

Comments (3)

Adobe’s love and hate for browsers

Adobe has 2 of the most popular browser plugins (see Common plugins for Firefox). Flash is by far the best way to deliver multi-media content to web users because of 2 reasons.
1. Same user experience on all platforms and browsers
2. Ability to stream

Flash Player Penetration is 98% of Internet viewers. This is great for any software! Adobe loves browsers.

Then why did Adobe choose to write Apollo outside the browser? Which clearly puts them On A Collision Course With Web Browsers. Here is why Adobe hates browsers:

From a end user perspective Flash has remained at (in)famous “skip intro” on web sites or as a media player to watch videos or listen to music inside the browser. Flash is not as popular for writing web applications as AJAX is.

The main reason for this is the “back button” in the browsers. Hitting the back button unloads the Flash application losing the application context and any interim session data.

Back button is one of the most used features in browsers. It is hard to change user behavior. This has restricted Flash usage to just media delivery on the web. This I suspect is also the reason why Apollo did not leverage existing browser plugin installations, instead decided to keep it outside the browser chrome.

Submit to digg Technorati Yahoo My Web
Technorati Tags: , , ,

Comments (11)

Flash or Java. Which is better?

Ed Burnette has written a blog post Is Flash better than Java? there is a lot of interesting discussion happening on the thread. The comparison needs to be sliced and seen from various angles.

Flash and Java is not apples-apples comparison

Flash is most popular for delivering media content. Most of Flash content is delivered thru browsers. Flash installations on desktops is predominantly because of browser plugins. Whereas Java can be used either as client-side applet for rich application UI or can be used on the server-side for writing the application code delivered to browsers thru HTML/AJAX.

Flash wins hands down if the comparison is with Java applets. But, the number of websites and applications that are powered by Java on the server-side out number Flash applications on the web.

Apollo and Java is not apples-apples comparison

Adobe Apollo is a cross-OS runtime for delivering Web-Desktop integrated applications. Java is a cross-OS platform not specifically for writing web-desktop applications. Java has a huge collection of platform neutral API for accessing OS, hardware, network, graphics, database etc. One part of Java is Swing (UI) which can be used for writing rich UI applications, again swing is not meant for specifically writing desktop-web applications. Swing is traditionally used for desktop only applications. So I would say Swing is more comparable to VB or X-windows rather than Apollo.

A more near comparison of Apollo on the Java side is Dekoh, which is a open source Java based platform for writing desktop-web integrated applications.

Which is better Java or Flash?

Depends on which aspect are you looking at.

  • Media delivery on the browser: Flash
  • Better execution (installation, upgrade, version changes) on client side: Flash
  • Number of web applications written using the technology: Java
  • Richness of API and services: Java

Technorati Tags: , ,

Leave a Comment

Desktop web applications and browser debate

In the last week there has been a lot of debate about Desktop RIA applications. Starting with Alex’s article on Read/Write web Adobe Apollo – On A Collision Course With Web Browsers and then a discussion Which is better, an offline Web App or an online Desktop App?. There were other articles including Zimbra offline announcement and a big discussion on need/use of offline apps here. Finally, I read this nice post from Mike Chambers of Adobe on Why Apollo?. He explains very clearly what Apollo is.  There are a few problems Mike outlines about delivering applications in the browser. Here are my thoughts and ways Dekoh overcomes them.

Conflicting UI:  Since the time Netscape introduced Back button, it has been one of the most used features of the browser. Most sites and web applications work fine with back button and expect people use them. How many popular web applications have you seen that do not work when you use back button? Back button is a problem for Flash based applications, it is not a problem for “web applications” in general.

Distance from the Desktop: For any browser based application there are 2 portions, UI on the browser and a server that serves the logic. When you include the server as part of the desktop platform (as Dekoh does), the distance between desktop goes away. Applications can very well render UI on the browser, as well as integrate with other native desktop apps.

Primarily online experience: Accessing exact same online application in a disconnected mode (Firefox 3?) is different from writing a desktop application that can provide some functionality offline and sync with online counterpart (like ebay demo of Apollo or Google calendar demo of Dekoh).  The online experience problem is relevant to former type. Writing desktop applications and accessing them thru the browser creates a consistent user experience, works across browsers.

Lowest Common Denominator: I agree there are differences between browsers when it comes to complex AJAX applications. But it is not too difficult to write applications that are very usable and run well on all browsers. There are also a number of toolkits that abstract the problem. Mike’s concluding paragraph coincides with my thought. He says The fact that web applications have flourished despite these drawbacks is a testament to the attractiveness of having a platform with a good development model that has the ability to deliver applications to multiple operating systems.

Leave a Comment