IwkMail, mixing WebKit Gtk+, Camel and JQuery Mobile

In the last few weeks, as part of my work here at Igalia, I’ve been playing a bit with the concept of hybrid applications. In this case, I’ve created a basic prototype of a mail application, with its user interface completely written using JQuery Mobile, and with backend code in C and GObject. The result is iwkmail.

Screencast of iwkmail in action

Though it’s a simple experiment, I’ve added some mail basic functionality, so I could try to catch as much as possible of real requirements for how we could improve the developers WebKit+GNOME experience creating hybrid applications.

My first conclusion is that it’s surprisingly easy and fast to develop such applications. Second, I could reuse tons of source code and modules from my old projects. This approach surely provides a way to create cool GNOME applications, using the most fashionable web client technologies.

So, you’ll get:

Browsing messages

Read/unread flags

Deleting messages

Creating and deleting mail accounts.

Storage protocols supported: IMAP and POP.

For sending mails, we support SMTP. There’s support for an outbox holding the messages to be sent.

A plain text composer, allowing to add attachments.

The UI is completely written in Javascript + HTML, using JQuery Mobile.

The backend side is done using Camel library inside Evolution Data Server, so we rely on a library well tested for more than 10 years. All the code related to this is implemented in C+GObject, and I reused a good set of code from Modest, the default mail client for Nokia N810 and N900. I’ve got involved on its development for 3 years, so that’s a bunch of code I know well enough.

For communication, I use the AJAX-like JSONP protocol, and custom SoupRequest URI scheme handlers. Basically I expose some methods as iwk:addAcccount, iwk:getMessage, etc, and arguments are passed as usual in a web request. The result I obtain from this calls is a JSON object with the results of the call. Simple, and works very well.

Oh, I guess it’s very obvious that I did not spend too much time thinking on the project name… So, anyone proposing something that matches the IM acronym (I don’t want to rewrite the class names!) would deserve a beer.

Last, lots of thanks to Igalia for giving me the opportunity to do this experiment. As usual, fun stuff to work with.

It’s just a prototype, so I still didn’t do any action to prevent this. My idea for implementing this is filtering the documents as they’re processed to be sent to webkit engine (in the ImContentIdRequest). So yes, the solution would be parsing.

Anyway, I’d also highlight that the iframes for body parts are running in a different domain per message. So, a page can only access the content id’s in the same message. But I’d prefer playing a bit safer and block javascript and iframes inside the body parts.

The fact is that I wanted to avoid calling JSCore directly, as it’s something that won’t be available in WebKit2 architecture. I just wanted something that I could migrate as soon as WK2 gtk has enough API to do it.