The idea I've been pitching to Orsini is the one where I'm on an airplane with no Web connection and I want to author a WordPress-based blog or write some Yahoo Mail-based mail. Theoretically, with JavaDB, I should just be able to fire up my browser, go to my bookmarks for either of those applications, bring up the blog or email authoring page, finish my work, and press the submit button. It could all work just as though I'm on the Web. But where the magic could really come in is what happens the first time I reconnect to the Web. Upon such reconnection, the Yahoo Mail I wrote would automatically synch up with the real Yahoo Mail and the blogs I wrote would automatically synch up with ZDNet's WordPress installation.
Taken one step further, if the architecture supported the use of a USB-based thumbdrive as the place where JavaDB stores everything, then, theoretically speaking, if all your computing was Web-based (eg: if you used Web-based email, word processors, spreadsheets, CRM systems, Wikis, blogs, etc.), you might not need a PC anymore. All you'd need is lots of Java-capable terminals with USB ports everywhere (kiosks, on the seatbacks in airplanes, in buses, at the office, at home, etc.).
Pretty much everything for this to happen is in place. In addition to support for Flash and Acrobat, a great many computing devices (PC, kiosks, etc.) already support Java though some may not have a USB port (also note that, because of its prevalence, some developers are experimenting with Flash to play the same role as JavaDB). Per a demonstration that Orsini has been giving that shows an online tax application that works if your connected to the Web or not, JavaDB clearly has the capability. Java even has USB support.
But to go beyond the simple tax app proof of concept that Orsini is showing, someone has to sit down and write the code. The code that makes JavaDB emulate the repositories of popular Web apps like WordPress and Yahoo Mail (separate code for each). The code to detect the loss of a connection and re-route all submits and gets to the JavaDB-based repository. The code to do the synching once a JavaDB-based repository (be it on a hard drive or a USB key) has a clear path to the real back-ends it needs to synch with. I'm selfish. I told Orsini that if he wants to generate a lot of publicity and make a lot of friends very quickly, to get it working with Typepad and Wordpress. No word yet on where he might be with that. But, in this weekend's email, he was clearly groking the idea of synch that I was talking about. Wrote Orsini of Google Browser Sync, "This does in a way reinforce the the notion of 'synchronized web' which we discussed."
It sure does. It's just the reverse of what we've been talking about with JavaDB because in this case, it's the repository on the Web that has to be tuned to what's happening on the browser side as opposed to the browser with JavaDB being tuned to some specific Web application (where JavaDB emulates that application's back-end). But the idea of keeping a browser's cache data synched with the Web, which is one of the things Google Browser Sync does, is only a stone's throw away from what Orsini and I have been talking about.
So, what exactly does Google Browser Synch (GBS) do? It's pretty simple. First, it only works with Firefox 1.5 and up. Second, once you install it, it synchs your bookmarks, cookies, saved passwords, history, tabs, and windows to an online repository that Google runs on it's servers (through its configuration screen pictured below, any one of these can be turned off. Third, once you configure your other installations of Firefox (perhaps at home or on another computer) with GBS, then all of your Firefox installations should stay in synch with each other.
In my tests, GBS asked me for my Google Account credentials (in my case, these were my Gmail credentials). Google associates your browser data with your credentials so that when you go to another computer that has GBS installed on it, it (1) knows where on Google's servers to find your synched data and (2) uses your credentials to securely access them. Google adds an extra layer of security by forcing you to assign a PIN to your Firefox data. Without the PIN, other GBS-enabled Firefox installations will not be able to get at your GBS data.
There are several obvious applications for GBS. The first of these, as previously stated of course, is to keep multiple browsers in sync. When I first discovered del.icio.us social bookmarkleting service, I was more excited about being able to access my bookmarks from anywhere than I was the social tagging part and I still use it for that purpose today. But the one thing it doesn't do (that I hoped that it would) is synch those bookmarks with my various Firefox installations. There's a way to fudge it. You can pick up the RSS feed that goes with any one of your personal del.icio.us tags and subscribe to it with Firefox's Live Bookmarking feature. But it's not synch. If del.icio.us is unreachable for some reason (which it sometimes is), any Live Bookmarks that live off my del.icio.us RSS feeds disappear. Another problem that I've noticed with excessive use of Firefox's Live Bookmarking feature is degradation in system performance. So, I've been using the Live Bookmarking feature very sparingly in hopes that one day, Yahoo (which now owns del.icio.us) would get some sort of synch working (as as side note, if everything universally and natively supported OPML, most of the heavy lifting needed for bookmark synching would be done).
Ask and you shall receive, I guess. I wanted bookmark synching. But instead of coming from Yahoo, it came from Google. That said, Google is still two steps away from taking what it has done (synching bookmarks, cookie, passwords, etc.) and besting de.licio.us. All Google has to do now is (1) give us Web-based access to the bookmarks it's already storing for us (can't be too difficult) and (2) take the tagging system it already runs for Blogger.com and make it available to GBS so we can tag our bookmarks.
The last two data types that are synched (tabs and windows) bears some explanation. At any given point, GBS is keeping track of what windows and tabs you currently have open in Firefox. If you shut Firefox down, if Firefox crashes (which it does to me occasionally), or, if you start up a GBS-enabled version of Firefox on another system, you'll get an opportunity, in very Opera-like fashion, to reopen those windows and tabs. Cool. One point, based on my tests, Google servers can only stay in touch with one GBS-enabled browser per Google account at a time. While using a GBS-enabled version of Firefox on one system and starting a GBS-enabled version of Firefox on another, the GBS plug-in on the first system notified me that it had been disconnected (see partial screen shot, above right).
The other (and final for now) obvious application for Google Browser Synch is system switching/upgrading. I know there are utilities for transferring everything on an old system to a new system. But, for some reason, some of the more nuanced stuff doesn't seem to make it over. So, at the very least, Google Browser Sync is a way to manage the transfer of some of your browser-based stuff. All? Apparently not (at least not based on my tests). The one thing I'd die for that didn't get transferred in my tests was Firefox's autocomplete-cache for filling out Web forms. Sigh. Also, my browser's settings (for example, the page I want launched -- "about:blank" -- everytime I open a new Firefox window or tab) didn't get transferred.
So, it's not perfect. But, if Google takes just a couple more steps in del.icio.us' direction (or, if del.icio.us takes a bunch of steps in GBS' direction), I'd be one extremely happy camper.