Day: February 12, 2007

My first todo item that I wanted to finish last night is now finished: I finished the support for both unsolicited EXPUNGE and unsolicited FETCH events. Together with the unsolicited EXISTS this forms the support for Push E-Mail or the so called IMAP IDLE.

There is still some work to also fully and correctly act on the changes in the higher tinymail layers. Most is acted upon already though. For example added and removed messages are pushed to the models of the user interface if you register the model with the folder observer TnyFolderMonitor.

Next on the list is finally going back to non-camel-but-tinymail-code coding. Although I think I must by now know more or less everything about Camel that there is to know, both its beauties and uglies, tinymail code is still far more easy for me. Probably because I designed it myself and because it’s designed exactly how I want it.

Dirk-Jan and Sergio have been finding various nasty pieces in both the API and implementation that I didn’t foresee when testing using the demo user interface. This is good and was to be expected. No human, not even a freak like me, can get things right from the first time. It’s not in the design of our species. The result of their pioneering will be a better library. One that just works. As usual, I’m only satisfied when it’ll be excellent. In the end, what’s the point in making it easy for yourself?

My opinion? Life is about the path to your results, not about the result themselves. Getting there is the joyful part … But maybe I just need a shrink? Or more time with Tinne, in sauna, in bed sleeping, on my skateboard and less time behind my computer screen?

Yes, maybe. Fucking coding addiction.

Although I still need to get acting on expunges 100% right, I just completed Push-Email and I already have a bunch of new TODO items for that little framework which I now started over a year ago.

Dirk-Jan asked me whether it would be possible for the folder model to get auto updated upon changes. Changes like when the “unread” and the “read” changed. But also changes like folder renames, creations and folder deletions. The idea will most likely be to let the folder model implement the TnyFolderObserver type, to register it as an observer of every folder that it stores in itself and to add some extra information to the TnyFolderChange delta or helper object. As usual, people can help me with this.

Another item that I want to get done is to read more of the unsolicited events from the IMAP server. At this moment I’m indeed reading unsolicited EXISTS and EXPUNGE responses. But there is also the unsolicited FETCH response that aids with getting the flags updated when they changed remotely. In combination with the already implemented CONDSTORE support, will this reduce a lot of the needed bandwidth. Not only will new messages be pushed and expunged ones deleted, but also will changes to the flags of your messages be auto updated (without a network-traffic expensive full synchronization needed).

Anyway, I have no idea how to get informed on remote folder renames, remote folder creates and remote folder deletions. I wonder whether the Lemonade group can do something about this? It seems that nothing in the IMAP specification makes this possible? Periodically doing a LIST in combination with STATUS doesn’t really sound practical to me.

At FOSDEM my plan is to give an overview of both future plans and the current state of the project. Last year at FOSDEM and at GUADEC I did a technical talk on design patterns and GObject. I think this one will be less technical in its nature. A little bit like my talk at T-DOSE. I mean, I only have 45 minutes or so. There’s no way you can do a technical talk in 45 minutes unless you focus on one micro feature. At T-DOSE I was lucky that my audience was still interested (which is very strange, I agree) and that it was lunch time. I wasn’t very prepared at T-DOSE though. I mean, I had been coding like crazy those weeks. I fear FOSDEM wont be much different.

Somebody on an IRC channel told that it’s better to burn out, than to fade away. I think it was our bugmaster Andre. He’s right. And thanks for those few non-coding moments on IRC Andre.