Akonadi goes Web2.0

Lots of people are posting about implementing functionality in web browsers to do what we do today in rich clients.

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:

Ogg link.

The video shows web pages in multiple web browsers showing the same data as KMail, KAddressBook and the proof of concept gtk applications I wrote about before, with everything kept in sync. They share the same data. I could edit the same data in the web pages too if I had taken the time to write the javascript code to handle it.

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.

Another use case is for developers who find it easier to develop application UIs in html and javascript instead of C++ or want to incorporate web slices. They could simply put their html into a QWebFrame, and they’re done. A new application without a recompile. Wacky ideas and platforms to host them. Check.

I knew that a web page showing Akonadi data would need to change asynchronously, and not cause a page to reload when selecting a mail folder. jQuery is a javascript library with facilities for exactly that and with plugin support. I used the jstree and dataTable plugins to put the page together. Check out the demos here and here of what else those plugins can do. Asynchronous user interaction. Check.

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.

Rather than learn the details of a Comet implementation though, I wanted a ready made solution to abstract the details away from me. Orbited is a Comet framework written with twisted which can be used with the comet server protocol and js.io, a javascript library simplifying network communication in javascript environments. I already had an implementation of a twisted akonadi client library to get the data to orbited, and Orbited would take care of the rest of the transport. In the browser html, js.io provides a listening socket to recieve all notifications and asynchronous data responses. A big thanks goes to desmaj on #orbited who got me started with a small contained comet server and client. All I had to do was add Akonadi bits to it, and a bit of jQuery glue later the result is in the screencast above. Akonadi in a real-time web application. Asynchronous two-way data transfer. Check.

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 😛 )

The implementation of this is messy because my C++/python ideas of how to write code and classes get thrown out the window when using javascript, mainly because the ‘this’ object in javascript doesn’t always resolve to what I expect it to when thinking in C++/python design mode. To get it done I did some ‘code sharing’ with copy and paste. It’s just a proof of concept anyway, so that doesn’t really matter. I’ve put the code in the same git repo with python-twisted-akonadi (Sorry V 🙂 ).