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 🙂 ).

16 Responses to “Akonadi goes Web2.0”

  1. anon Says:

    This is AMAZING!

    I hope Akonadi and this will be easy to install on usual private webspace so data can be accessed anywhere for users without having to rely on the usual data-harvesting service providers.

  2. pier Says:

    I think that an other usecase could be to put akonadi on a personal home server which may serve all the different computers in the home!
    That would not be too much demanding in terms of resources ^_^
    Or maybe the server copy may act only as the backup for the other instances.

  3. schnebeck Says:

    When its easy to port Akonadi on another platform say ARM linux based Maemo with this web client (a little bit more polished) you have instantly a workable client – on a smartphone I like the concept to use server data directly far more than any crappy synching.



  4. mie Says:

    Awesome work.

    Hope this pays off, and you become default on many platforms 🙂

  5. Pau Garcia i Quiles Says:

    Instead of developing all the HTTP server, AJAX, Comet, etc stuff, you could use Wt. There is a library (wtwithqt) which makes it easy to combine Wt and Qt, it’s in the examples directory.

    BTW I’m working on something which might be useful: WtDesktop – using Wt to develop desktop applications, like Google Gears but based on Wt + QtWebKit.

  6. CHRI2 Says:

    the automatic update of the email-adress from the kde adressbook is THE KILLER ! BURNER !

    great work!

    question how does it scale up to 10k mails ?

  7. Kevin Kofler Says:

    pier wrote:
    > I think that an other usecase could be to put akonadi on a personal home
    > server which may serve all the different computers in the home!

    Not just that, but also mobile devices, computers in cybercafes etc. Basically, wherever you’d use some third-party webmail, you could use Akonadi’s running on your home computer instead (but you’ll need support for composing mail, not just viewing as in the current implementation).

  8. CHRI2 Says:

    do you plan to add an UI for adding and configuring Akondi Resources ?

    Like adding Gmail syncer to Akonadi by webfrontend…

  9. steveire Says:

    Yes, I think using a web browser based client to access an akonadi server on a home server or other private web space would be another good use case for this.

    Not everyone has a home server though. I don’t at least. 🙂 I don’t think it would be too demanding in terms of resources either, even if one home server was serving data for multiple people. There would have to be one akonadi server per person in the home, but that’s not a problem either I think.

    I have more ideas for sharing data between different akonadi servers on different computers too, but that’s just an idea so far.

    Akonadi should be portable to the Maemo, but we haven’t tried to do it yet. We will start investigating that more though in the coming months.

    Wt does look like a great project. Love the library name by the way: “Woot with Cute”. I didn’t chose to use it this time because I wanted to demonstrate that Akonadi can be used without writing C++ code. Additionally, I wanted to have some exposure to some of the details of how this web technology works. To get this beyond a proof of concept project, it looks like wt and WtDesktop would be worth more research at least. So far, I’ve been trying to demonstrate that it is possible to write Akonadi clients for any platform with just a runtime dependency on libQtCore and some other non gui parts of Qt.

    I have no idea how this scales up to 10,000 mails yet. Currently there’s some very inefficient loops in the python and in the javascript code. It is written that way because it was quicker than making the applications quicker :). I suspect though that it would be possible to get acceptable performance while handling large amounts of data. Many of the performance tweaks we have in the C++ code and in the Akonadi server itself can be used or reimplemented in other APIs such as this.

    Mobile devices powerful enough to run a web browser, but not powerful enough to run an Akonadi server would be good candidates for using this stuff, yes. Support for composing mail would not be difficult, but there is a lot of code in the akonadi python API which would need to be written first. We’ve been writing the C++ Akonadi API for a few years now and we’ve learned a lot. I think a full low level python API could be written in one or two months, and high level API like the gtk or browser stuff would take a few more. We just need champions to do it. 🙂 kde-pim@kde.org

    Making it possible to implement resources in the python and comet API is certainly within scope of a complete implementation of this stuff. It would in theory be possible to write a resource with a connection to a web based service like gmail which maintains a resource, but it’s not necessary. That’s what IMAP is for, and GMail already offers IMAP access. For services which don’t provide IMAP, that might make more sense, or it might be time to jump to a service which does support IMAP.

    Thanks for the comments.

  10. schnebeck Says:

    maybe also worth to take a look is:
    lika a pure Qt version of Wt.



  11. GoblinX Project » GoblinX Newsletter, Issue 223 (10/25/2009) Says:

    […] https://steveire.wordpress.com/2009/10/24/akonadi-goes-web2-0/ […]

  12. Links 25/10/2009: GNOME 2.28 Reviewed, PCLinuxOS Turns 6 | Boycott Novell Says:

    […] Akonadi goes Web2.0 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: […]

  13. oiaohm Says:

    Only thing still missing is a console application to access Akonadi for the few people who ssh into boxes or have X11 crashed for some reason.

  14. iamronen Says:

    Hello Steve,

    I came across your writing in the Raindrop project… and from what I was able to gather about Akonadi – it fits really nice into a vision I have been trying to consolidate for some time… http://www.iamronen.com/ontekusuto … so I thought I’d drop a line here.

    I would love to have an always-synchronized Raindrop like integrated-communication application that is hosted on my server and that I can access either directly from my blog admin, desktop application, mobile apps etc.

    If I understand correctly what Akonadi is – it sounds like a cornerstone technology in my dream!

    All Things Good

  15. steveire Says:


    Thanks for your comment. Akonadi could indeed be the cornerstone technology you are looking for. I think eventually it would be a good idea to investigate more of how Raindrop and Akonadi can access each others data and provide a user controlled globally accessible PIM storage from multiple devices. You are not the only one. We share your dream! 🙂


    Yes, a command line Akonadi client could be a good thing. There is already one existing in playground/pim/akonadi, but it has not seen any development in a long time. It was one of the first akonadi clients created for testing purposes.

    It might eventually make sense to revive it or use the python API to create a new command line client. That is not a high priority at the moment, but we can help anyone interested in getting it done.

  16. Data fragmentation between ‘owning’ services? « Steveire's Blog Says:

    […] think it depends on something fictional like the KDE desktop environment, which is clearly not the case. The point is though that non-adoption of common infrastructures between different applications is […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: