Solving the “Offline Problem”

Simon points to Berlind who examines Sun’s JavaDB (AKA Apache Derby, AKA IBM Cloudscape) as a potential option for solving what is (un)affectionately known as the “offline problem” amongst thin client advocates such as yours truly. The very same problem experienced by yours truly a couple of hours ago, when I couldn’t complete a planned entry or my About page due to the inability to access resources on the network while flying.

Now Alex may be correct in his ironical but possibly accurate speculation that we’ll solve the offline problem in time for it to be irrelevant, due to nearly pervasive wireless. But I still believe that it’s a significant problem – one that represents a big opportunity for the project(s) that address it adequately. It’s also a problem that seems to have fallen victim to sog’s first law of technologists: that which can be overthought, will be.

I don’t need sync or universal offline access to every site that I might visit; a half-way solution that would work for me at least would be having the ability to pick a site or two, say Alex’s FeedLounge, and just caching that. That’s it, that’s all I want. Easier said than done, perhaps, but a simpler problem than the one being solved in some quarters.

Which brings me back to David’s piece. He opens by discussing a demo given back in December by Sun’s Francois Orsini (which impressed the very sharp Ted Leung at the time), wherein SunDB/Derby served as the offline persistence mechanism for an Ajax application. Cool stuff, no question. And a step in the right direction. Berlind extrapolates from there envisioning a persistence mechanism that serves:

…as a repository for office productivity documents (Microsoft Office, OpenOffice or any one of the new breed of AJAX driven offerings for which JavaDB could be perfect). All that would be needed is some sort of software shim that makes the JavaDB look like a filesystem.

Believe me, nothing would make me happier than being able to not only cache FeedLounge, but have offline write access to something like our JotSpot Trackers or Writely. But I am concerned that this runs afoul of sog’s aforementioned first law of technologists.

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.

None of this is to say that Berlind’s wrong and the problem shouldn’t be worked on; it can, and should. And maybe Berlind, Bray and Phipps have a point and JavaDB’s that mechanism, and maybe it’ll be something else. It’s too early in the game, IMO, to make that call. What I’m most optimistic about at this point, however, are solutions that keep their ambitions limited. Solve the simple problems first, because I don’t want to wait until I have universal network access for offline access.

In the event that you’re interested in this sort of thing, I’d be sure to keep an eye on two efforts that Alex alerted me to last time we had lunch: Dojo.Storage, which leverages Flash’s persistence mechanism (as does Julien’s offline wiki which I still can’t use because Macrobe hasn’t released a Flash Version 8 for Linux), and Firefox 2.0, which apparently is struggling a bit with the resourcing for its offline functionality. Anybody know how they’re tackling that, incidentally? Bulked up flatfile persistence? Relational model?

Either way, I’m expecting to see better offline abilities within one or more of the browsers within a 12 month timeframe. Should be great.

Update: As Jeff Waugh indicated in the comments, Firefox’s mechanism is not JavaDB but SQLite – I’ve speculated on that possibility before. Sun’s Dave Johnson has more on this here, and provides a link to the mozStorage project.