Progress Toward an Offline e-Learning Client?

One of the most beloved aspects of the SUNY Learning Network’s current Lotus Notes-based homegrown LMS is its offline capabilities. Faculty members can download the current course data–including student discussion posts, tests, etc. They can respond to posts, grade papers and tests, add announcements, and so on, all while offline, and automatically synchronize the next time they have a connection. People who haven’t used this capability (especially those who always have a broadband connection handy) don’t understand the value of this affordance, but I do. It’s for the same reason that, much as I love my GMail, there are times when I really need an email client that can work offline. Or an offline RSS feed reader. Sometimes, it’s really handy to not have to be connected. And that’s doubly true for faculty members who are not gadget freaks, live in rural areas, and are unlikely to have ubiquitous broadband (or any broadband at all).

Anyway, like it or not, we’re on the hook to reproduce that capability in our next-generation system. This is a somewhat daunting challenge. Not that it’s rocket science; synchronization has been done many times in many different ways, and there are any number of existing code bases that we could draw from. Rather, it’s daunting because it’s a lot of work to do at all and a lot more work to do right. Developing and, even worse, QA testing a cross-platform fat client in an environment where you have no control whatsoever over the profile of the client machines is a pretty large task, even if you draw on an existing cross-platform technology base such as Eclipse RCP or Mozilla Firefox.

A while back, I wrote a bit about some relatively new possibilities for re-implementing the fat client experience with…er…less fat. At the time, though, I was focusing more on the user experience; I didn’t really get into the whole synchronization issue.

As of yesterday, it looks like there may be a nice, lightweight solution to offline synchronization on the horizon, courtesy of none other than Ray Ozzie–the original inventor of Lotus Notes and now Microsoft’s CTO.Ozzie announced Microsoft’s creation of a (Creative Commons-licensed) extension to RSS called “Simple Synchronization Extension,” or SSE. The basic idea is to turn RSS, which is essentially a one-way publishing protocol, into a two-way sharing and syncronization protocol. Here’s a description, from the FAQ:

SSE defines the minimum extensions necessary to enable loosely cooperating applications to use RSS as the basis for item sharing-that is, the bidirectional, asynchronous replication of new and changed items among two or more cross-subscribed feeds.

For example, SSE could be used to share your work calendar with your spouse. If your calendar were published to an SSE feed, changes to your work calendar could be replicated to your spouse’s calendar, and vice versa. As a result, your spouse could see your work schedule and add new appointments, such as a parent-teacher meeting at the school, or a doctor’s appointment.

SSE allows you to replicate any set of independent items (for example, calendar entries, lists of contacts, list of favorites, blogrolls) using simple RSS semantics. If you can publish your data as an RSS feed, the simple addition of SSE will allow you to replicate your data to any other application that implements the SSE specification. [Emphasis added.]

“Any other application” in that last sentence could be an offline editor. So, for example, if we can RSS-enable a discussion board (and we know we can), then we can extend the model to allow offline replication, editing, and syncronization back with the LMS server.

Ozzie notes on his own blog that this implementation is very much like Notes replication in some ways:

Notes had just about the simplest possible replication mechanism imaginable. After all, we built it at Iris in 1985 for use on a 6Mhz 286-based IBM PC/AT with incredibly slow-seeking 20MB drives. We were struggling with LIM EMS trying to make effective use of more than 1MB of memory. Everything about the design was about implementation simplicity and efficiency. So if simple is the goal, why not just adapt the Notes replication algorithm to this need? Notes “notefiles” could be analogous to RSS “feeds”; and Notes “notes” could be analogous to RSS “items”; and Notes “items” could be analogous to XML “elements”.

Notefiles replicate by using a very simple mechanism based on GUID assignment, with clocks and tie-breakers to detect and deterministically propagate modifications. Something like this could easily be represented in XML. Notefiles replicate with one another in a decentralized, masterless manner; feeds could be “cross-subscribed” in a similar manner. There’s no magic to it once you know specifically what you’re trying to accomplish, but it certainly helped to have an existence proof.

And so we created an RSS extension that we refer to as Simple Sharing Extensions or SSE.

Nice. I frankly don’t follow all the tech talk 100%, but what I do get is that we have an underlying mechanism that works something like the one that SUNY faculty rely on and like today. That means we have a shot at being able to replicate (pardon the pun) the current capabilities–but on modern, lightweight, standards-compliant technology. So far so good.

It gets better. John Udell, in his post about the new extension and similar (possibly complementary) ideas coming out of Google, refers back to a previous column in which he describes seeing a proof-of-concept from BEA called “Alchemy”:

Current approaches to taking browsers offline typically queue messages that later update in a server-based data model. An Alchemy application, though, always works with a genuine local data model that it stores as sets of XML fragments and navigates in a relational style. Bosworth’s hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need – both offline and online. Nothing prevents Java, .Net, and Flash clients from adopting the same strategy, by the way. But if Bosworth is right, the universal client that we know and love could get a new lease on life.

So now, not only can we replicate content items, we can also replicate relational data–data that we could query to generate reports, and so on. We have a mini synchronized relational database, represented in XML, and cached locally. All through the browser–no fat clients to install, no proprietary data formats, no disconnect between the offline and online user interfaces.

Admittedly, Alchemy is not production code that anyone can look at just yet (although Udell’s post on the topic is 18 months old; I wonder how much further along the project is today). So this approach isn’t completely baked yet. But it seems that we are rapidly moving in the right direction. SSE is here today, and we could at least consider using it for offline authoring, monitoring, and editing. Frankly, I don’t believe that our current SLN system runs a huge number of queries for faculty in courses anyway because it’s so expensive to do so (computationally speaking) in Notes’ document-driven system. So SSE alone may be close to what we need.

It’s a good time to be alive.