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:
Responded Orisini (edited for punctuation):
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.