Blog on JavaDB sparks debate over thin clients, AJAX, and synch

Yesterday's posting regarding JavaDB (see JavaDB: An idea whose time has finally come) has sparked a glass-half-empty vs. glass-half-full debate between ZDNet reader Justin James and Sun's Francois Orsini that drags the idea of thin clients and AJAX-programming through the mud a bit. Whereas  James sees little or no merit to AJAX style programming, thin clients and JavaDB, Orsini argues that different use cases call for different models and that AJAX and JavaDB have something to offer in certain scenarios.  Wrote James:

[The people who disagree with me] fell off the same rocker you did too when [David Berlind] drank the AJAX Kool Aid. Have you ever tried writing a piece of AJAX? It is extremely difficult for even the [best] coder to write anything that is even moderately complex. There are browser incompatabilities all over the place; blame whoever you want (browser maker of your choice), that does not change the basic fact. More importantly, the problem with JavaScript isn't just the language itself (although it is extremely weak, even as far as scripting language go), but the interpreters! I don't care if you have Donald Bloody Knuth himself writing the code, it doesn't change the fact that JavaScript interpreters are slower than molasses. Try iterating through a few thousand objects in JavaScript, which is exactly what your little JavaDB scenario will want to do. It will take literally tens, hundreds, or even THOUSANDS of times as long to execute as comparable code outside of the browser. I know. I have done it....Even James Gosling says that AJAX development is incredibly difficult.

Responded Orisini (edited for punctuation):

I don't have to iterate through thousands of records via Javascript - JavaDB supports Java procedures so if I get into some performance issues, I can move the iteration part at the Java engine level and not the Javascript one...Javascript is weak as a scripting language? I guess you are *not* talking about the Rhino engine, are you? Weak in which aspects if I may ask? ....Ajax is a web development methodology - nothing else - It serves a very specific purpose and by looking at how it is being adopted by many popular applications, I fail to see how it would be useless and a possible failure.  Is there room for improvement? Sure there is plenty.  [I] completely agree with this. But Ajax [allows developers] to enhance a lot of Web applications out there as well as creating some next generation ones, and this fairly rapidly.  As far as its complexity [is concerned], well it's everyone's opinion here.  I don't find it complex myself.  But I agree there is room for improvement, Yes.

There are plenty of other tit-for-tat points made by both men and I've invited both to go verbal on the debate with a podcast that I'd host.  Additionally, Sun's chief open source officer Simon Phipps chimed in via his SunMink blog where he sums up my offline-enabler sentiments regarding JavaDB with two words: Local AJAX.  Exactly.  Call it a thin client.  Call it a rich client.  Call it an off-line client.  I don't care.  Imagine if AJAX-based apps could work off the data they need to (or create data) whether there's an Internet connection or not.  JavaDB can serve as a facilitator of Local AJAX when the resources across the Internet that AJAX apps normally connect to are inaccessible for whatever reasons.  Then when the connetivity returns, the local JavaDB-based cache can be synchronized with on-line data.  Via email, Phipps took an even bigger picture view that was more interesting:

I think this is finally the true usage of Java applets emerging, as helper classes for AJAX apps. François calls this "Local AJAX" but I even think it has applications when connected, and not just for resyncing offline stuff. Imagine adding encryption classes. Or a tiny Jabber server than can then use your IM as a UI for your app..

Helper classes for online apps?  Oy.  Hadn't thought of that.  Of course, for JavaDB to serve as such a platform (where the sky's the only limit on innovation), glass-half-full developers who like to push the envelope have to give it a shot and some might not be ready for that yet. Why? Well, as evidenced by JavaDB alternatives that also tackle local persistence, I'll bet that many are interested in the "L" word (local). For example, RedMonk's Stephen O'Grady joined the JavaDB conversation with a pointers to Dojo.Storage -- a technology that leverages Flash's persistence mechanism.  This in turn raises the thin (or rich) client architecture question. If a de facto standard for the basic utility of such a client emerged (utility that all developers could count on being there), what would that utility be? A browser with Java support?  A browser with Flash support? USB (to facilitate the key-fob computer)? Support for all three and maybe others? Standardizing on too many plug-ins or leaving the plug-in architecture of a supposedly thin or rich client completely open for dynamically loadable "helper classes" (perhaps from a USB key) eventually gets us right back to where we started (and to the one thing we're trying to avoid in the name of cost and complexity): a fat client (in which case, developers can count on pretty much everything being available).

O'Grady also hits me up on the synch issue: something I didn't adequately cover in my JavaDB post.  Writes O'Grady:

The problem as I see it in this case isn't the persistence itself; that's easy. Whether it's a file system approach or some sort of database - hierarchical, object oriented, or relational - to me is not the question. The problem, as far as I can see, is syncing: it's difficult enough with rather regimented schemas such as contact databases. For something like a spreadsheet or text document, the problem would seem to be considerably more complicated.

Synching is a point that I addressed in a subsquent post (see More wag the dog: Mobile databases not exactly free).  Judging by the amount of synchronizing that's taking place out there in IT-land, there is huge value to synchronization.  The problem is that there's virtually no standard way to do it (compounded by the multitude of dissimilar data formats at the end points).  In the majority of places where synch is taking place, it's invariably governed by expensively developed and hard to maintain custom code or by a canned solution from a vendor that specializes in synch. 

In either case, there isn't a lot of flexibility and generally speaking, where there's IT rigidity, there's usually opportunity.  Opportunity for standards.  Opportunity for innovation.  Opportunity for open source (to remove the proprietary binds that are in the way). For example, in the same way that some open source project could open up synchronization between Microsoft's handheld version of  its SQL database and a centralized MySQL Server, it could also build a bridge between Local AJAX-driven (L-AJAX) Web authoring (using JavaDB, Dojo.Storage, or whatever) and the MetaWeblog API that services many of blogging systems out there today.  There must be some commonalities to these and other synchronization problems that are fodder for an innovative standard.  Dating back to his days working on Lotus Notes, and then Groove  (both of which can credit their success to synch), and now at Microsoft,  Ray Ozzie -- the king of synch -- must think about this stuff in his sleep. Under his watch, perhaps Microsoft's Creative Commons-released Simple Sharing Extension to RSS is a starting point for addressing some of those commonalities.  Today, I'm aware of several innovations in the works where SSE is being used in an AJAX-driven context to synchronize data across multiple domains.  Why can't your USB key be one of them?

I'm with Orsini on this.  The glass is very much half full.