I don’t know what’s going on, but I didn’t want Akonadi to miss the party. At the recent Akonadi sprint, I decided to spend some time putting together a proof of concept for a web client for Akonadi. Here’s a screencast of the result:
One of the advantages Akonadi can bring is to free us from the web browser and put our data and user experience into rich clients. Why the perversion of putting it all back in to a web browser? Initially, I started writing it just to try out the rich web client technology webby people talk about, and to see if Akonadi has what it takes to go Web2.0. First requirement is a catchy name. Check.
The zeroth requirement for any application is use cases. Where could an Akonadi web application be used? One idea would be to put a finished version of this technology onto a public web server and allow the public to create accounts and connect to multiple different data resources like email providers and unify them all in a single interface like many people do with KMail and other rich desktop client apps. However, that would not be practical as a service to provide to the public. Akonadi is designed to handle lots of resources for one single user. Using it to handle lots of resources for lots of different users probably wouldn’t scale in its current form.
I can think of two valid use cases though. Consider for example gOS, or Google Chrome OS, which encourage the user to access everything through a web browser and seem to be targetted at particular segments of netbook users. To access different email services on a gOS system, users would have to access different web applications each with different interfaces, and different usability designers deciding how to interact with the system. Using Akonadi in a web client, vendors like gOS and others could design one consistent interface which allows users to access all of their data of any type. Because the server and the client are on the same machine, the vendors would have complete control over the appearance and interactions with the system. Users who want to try out a rich client application can just install KMail and pick up where they left off. No need to import the data from elsewhere (and creating diverging copies). The data is already shared.
The web browser needed a way to get data from Akonadi into the browser when requested. That means implementing a server capable of responding to requests from the web browser, and capable of communicating with Akonadi on both parts of its interface, D-Bus and IMAP. Finally, I needed a way to deliver change notifications to the web browser without the browser requesting anything. This is variably called HTTP pull, long polling and Comet. I first saw it described here last month, which covers the concept pretty well. Rather than needing to keep events synchronized though I only needed to keep sending notifications from Akonadi (which may be rare) to the browser.
I noticed yesterday that Mozilla announced Raindrop. They’ve clearly spent more time on it than the two days did. I haven’t looked into their implementation, but it’s interesting to note both of us trying out these concepts at the same time. Multiple different projects with similar but distinct goals. Check. (Akonadi is a cooler name anyway 😛 )