We got a few posts lately of people recently hired by KDAB, and suddenly it made me realize that I didn’t make such a post when I got hired… almost two years ago. I guess it’s a wee bit late to write one now. :-) Buuuut… I figured out that I could post something about what I’m doing in KDAB (OK! OK! Sebas has been kicking me for days to make it happen). And if that proves to be enjoyable writing for me, and enjoyable reading for you people I may do that again from time to time. So what am I doing in KDAB these days? Well, for a while now I’ve been helping the pimsters with the refactoring of our PIM suite toward making it purely Akonadi-based. There’s quite a lot of work going on in this particular space, and I’ve been focusing mainly on the IMAP support. It has been an interesting journey so far which started with evaluating the IMAP stacks we could reuse. First on the ranks were obviously our old ioslave which served us well, and some IMAP code Tom Albers developed for Mailody. It turned out that we had to abandon the ioslave. It served us well for years, but didn’t work for some of the plans we had (most notably for adding the IDLE support I’ll talk about later). While working on IMAP I had a couple of ideas on how to still use the old ioslave, but they were really nasty and hackish… I think it was a clear sign that the ioslave reached its full potential and keeping it alive was a dead end for the future. So after this investigation phase it has been decided to write a small library for IMAP. We already had some codecs convenience in the KIMAP library from kdepimlibs so we stepped up to extend it. And for the API we quickly settled on a job based one because we had strong needs for asynchronous operations. We clearly don’t want to be blocking waiting for some IMAP command to be processed. So our dear old KJob friend has been used for that, and it turned out to be a very good choice. We’ve been relatively quick at having enough useful jobs implemented in the library once I wrote the core bits of the API. I got quite some help from Andras Mantia for that. By the way, I think that just like our almighty David Faure, Andras is having a few clones himself, once he gets on a task he going so fast you’d better not be on his way… something suspect is at play there, I’m sure. ;-) In any case, Andras (and his hundreds of clones) help was welcome, as it helped me move higher in the stack and work on the Akonadi resource itself. I’ll just slow down a minute and explain for those not in the known what an Akonadi resource is (for the ones in the known, you can skip to the next paragraph). So Akonadi is our grand unified layer to access data in your desktop, applications talk to it and then they have to understand only the akonadi concepts (in short: items, and collections of items). Of course you need to get your items and collections from somewhere, and that’s the role of Akonadi resources. They just get data from “somewhere” and put it in the Akonadi cache where the applications can make use of them. Obviously for a future Akonadi based KDEPIM suite we needed an IMAP resource to access your mail on IMAP servers. And if you followed closely, that means that soon applications won’t even need to know where the data comes from, you write just an Akonadi client and it can go over: POP, IMAP, whatever! It all depends on the resources your server loaded. Neat huh? Work on the IMAP resource started only a few days before the Akonadi Sprint in Berlin which I was attending. And the job based API quickly proved that it was the right choice. I’ve been pretty quick at building the resource on top of it (and Andras was producing new jobs for my own consumption at a furious pace). At this meeting we had kind of an informal contest about who would come up first with an Akonadi resource which can list a mailbox (since at the time POP, IMAP, and maildir support were all developed and started around the same time)… it turned out that I heard about this informal contest when I was putting the finishing touch to the mailbox listing. Sooo… DONE! :-) I didn’t stop there of course as more features were needed to have a complete resource. And I’ve been working on that almost exclusively during the sprint. Discussing with Volker (aka the Akonadi overlord, the alpha and omega of its design) we came up with nice design ideas for the groupware support (in particular Kolab)… but that’s probably a story for another time… Some time after the sprint, I flew over to other tasks in PIM land. And left the Akonadi IMAP resource untouched for a while. I came back to it only last week to implement in trunk one long requested feature: the IDLE extension. – And obviously that’s where the name of this blog post come from, just like my favorites novels you get the title only in the last chapter or paragraph. :-) – Thanks to this extension, if it is supported by the server, you get notified from changes by the server itself. For instance, it is not needed anymore to poll every N minutes to notice that a new mail appeared (I think this feature is sometimes called “push mail”). For the user that means, that the IMAP server can now notify the client of new emails, emails “arrive” faster at the user, and you can save a lot of unnecessary mail checking. Really handy! I committed IDLE support in trunk this week, so it will get released with our 4.4 release. In the meantime you can start playing with the Akonadi resource when our 4.3 release will be out, as we already ship it there (although it’s not used by default, see it more like a pre-version of what’s coming, for instance this one doesn’t support IDLE). That’s it for today, I hope you enjoyed those pimsters news from the trenches of the IMAP battle. See you later!