Month: February 2007

Oeps, some people are blogging that Modest is available. I guess that means that there’s no more escaping it. Its code is indeed available at http://modest.garage.maemo.org.

I would like to warn though, that both Tinymail and Modest still need a lot of work. It will not yet replace your Evolution. Whether or not it will eventually do that, depends on you wanting to invest time in this.

This is indeed an invitation for the community to get involved in creating both a framework for creating E-mail applications on mobile devices, and an E-mail client on top of it that might someday be used on both your desktop and your mobile device.

People are working on the IMAP code and Lemonade, on the POP3 code, on the code for handling the local cache and summaries, on language bindings. At FOSDEM I announced my plan to build-up a network of competence around the project. Nokia is interested, OpenMoko is interested, the One Laptop Per Child project seems to be interested. Igalia did some work, Kernel Concepts did some work. A large list of contributors did some work.

So, let us make this another success story like the Telepathy framework is for VoIP. And what can you do? A lot!

Maybe integrate Telepathy/Galago with an optional tinymail component like a summary and/or message view? Integrate a calendaring application? A contacts one? Enable the integration in Modest? Or maybe you prefer to do a language binding and write your own mail user agent? Or use the existing Python language binding for that? Maybe write a ui for timsieved (a daemon for deploying Sieve scripts) and that way make it possible for normal people to have server side filtering of messages into mailboxes, configurable with their cellphone? Maybe write a SyncML observable for the Push E-mail features of tinymail? Help me implementing more of the Lemonade IMAP enhancements? Help me with improving the summary code? Maybe integrate it with an existing desktop searcher and indexer, making searching E-mail on your phone possible? Melting E-mail, MMS and SMS together? Porting to WinCE? Why not?

There really is a huge to do list. It’s simply not doable for one person to ever finish all of the possibilities of what E-mail can and should offer to mobile users.

Oh, by the way. Implementing something that plays a sound when a new message arrives (a Push E-mail event) with the current API (just to show what tinymail can already do for a mobile device like a cellular phone):

public class OnMsgArrivesBeeper
	implements Tny.FolderObserver
{
   public void update (Tny.FolderChange change)
   {
      Tny.FolderChangeChanged c = change.get_changed ();
      if (c.ADDED_HEADERS)
         Phone.PlayRingTone (RingTones.NewMsg);
   }
}

So tinymail has these default components. And people have been confused by them as it causes them to believe that tinymail strictly depends on Gtk+ (or whatever it also supports through those default components). This is not true. In fact, I put a lot effort in making sure that I don’t depend on anything that might make it impossible to use tinymail on a different architecture.

I, for example, foresee that someday those who are building web applications want to use tinymail. What does this mean? This means: forget the availability of signals, most uses of singletons, the mainloop and some other things that I have yet to discover. Also forget the availability of things like gdk_threads_enter and gdk_threads_leave in the core library: I would have to link with the gtk+ libraries for this .. nope, not possible.

So, whatever you have been telling your friends about tinymail’s dependency on gtk+: you were probably wrong. Although you might have seen “Gtk+”-code in its distribution, it doesn’t necessarily depend on Gtk+.

Nevertheless are some of these components becoming powerful tools when you want to create quickly a Mail User Agent. This weekend I finished letting a GtkTreeModel type implement the TnyList, the TnyFolderObserver and TnyFolderStoreObserver types. Don’t worry, don’t worry, I’ll explain.

Well, I explain it here. That’s the documentation of that type. Because I figured that, well, a powerful component is worth nothing for the vast majority of you software developers, unless I document it. Right?

So I documented it. I, indeed, want tinymail to excel in its documentation.

Note that the vast majority of components in tinymail are optional. Being the application developer, you choose the ones you will use. The vast majority can be disabled at compile time, too. Tinymail is about the interfaces between the many components. Their implementations are reimplementable, inheritable, choosable, replaceable, …

Update: same story for this component (a list model for a folder summary): here. This one also documents how to get Push E-mail (Imap’s IDLE support) to auto-update your summary view, with tinymail.

I added basic folder management to the demo user interface of tinymail so that people can start testing this. The framework itself had this since long, but now I’m going to really start testing it. That’s because a Modest release is coming closer too. It’s of course going to be one of the basic functionalities of that MUA. The trivial stuff has to work too.

Basic folder management means creating, deleting and renaming folders. What you will be testing, if you are going to, is the entire thing behind all this: error reporting, creation on the IMAP service, creation of an instance for this, memory and reference counting when the amount of folders change, the folder observer stuff: does the view get updated?, the local cache refreshing: is the folder also removed locally?, etc. So when reporting bugs, don’t just focus on crashers. Not seeing it crash doesn’t mean that it worked. Go after the entire thing. It has to be a.b.s.o.l.u.t.e.l.y correct (can you imagine the despair of a user who has lost his INBOX because of a recursiveness mistake? I can, been there done that with another MUA).

For that reason we have the testing infrastructure. Please, please, people, I beg you, don’t yet use this functionality on your real accounts. I have set up testing servers: so I really did all that I can to give you the testing tools. Don’t use it on your own & real accounts. Final warning.

I also documented how to start using the testing servers in tinymail (I think it’s in the README). I even recommend only configuring those accounts. If you don’t configure any other account, no harm can be done. The testing infrastructure recovers automatically from disaster each 3th hour on IMAP2 and each service restart on IMAP1. Don’t worry about trashing it.

Sergio and Dirk-Jan are often discussing in parallel with me on software development of tinymail over instant messaging, so I decided to start an IRC channel on the topic. People with questions or who are actively developing on or with tinymail are invited to #tinymail on GimpNET.

Today I finished the observer stuff. You can register an observer to both a folderstore and a folder and get notified about folder renames, header adds and removes, count changes, folder removes and folder deletions (and other things). The default ui components will all auto act on such changes (by auto updating themselves as good as possible). You can of course register your own view (or model) as an observer of a folder too.

The observer/observable part of tinymail is the core-principle of the Push E-mail feature too. Actually of all the changes that need action use it. Implementing the role that the observable plays is what is flexible about this: It doesn’t matter whether it’s IMAP IDLE doing this, or an event coming from SyncML. And maybe tomorrow we will get these notifications from the telephone network just like how SMS messages are also being notified to our phone software? That tomorrow will be possible with tinymail’s infrastructure. Or maybe will some network start supporting some way of communicating this information over GPRS without needing an active TCP/IP connection? Maybe we need a small kernel module to communicate this to the application layer? Using D-BUS maybe? Multicast? inotify? Four such techniques at the same time? Pickable by the user as a plugin? A closed-source one from PhoneCodersDotCom? Also that will tinymail’s design for this cope with.

So .. this: gimpnet.#tinymail.add_observer (you), where ‘you’ is an instance of a type that implements an update method. And a ‘foreach observer o: o.update()’ in the channel type whenever something happens (Don’t call me, I call you). And not this: while (true) you.pollforstuff (gimpnet.#tinymail). It’s sooooo simple, but you would be surprised to see how many projects and cowboy-programmers get it totally wrong over and over again.

After all these improvements to the IMAP code of tinymail I have put in place all the infrastructure to support incrementally loading the summary view (the thing that shows the headers of your E-mails) while you are downloading it in the background.

Polymer and Telomer do this too by the way. Which is why it looks so fast. On top of that it uses pipelining. This makes it possible to queue multiple commands on the server and then letting it start replying the results for them.

So basically, while using a single connection, Dave managed to allow the user to start downloading and viewing your summary while that user can already start viewing messages too. Using lots of clever techniques, tricks and most importantly a lot knowledge about how IMAP servers work. I would, by the way, hereby like to thank Dave for his help on IMAP while I have been improving things for the last weeks.

The idea is indeed to get tinymail there too. As I said, step by step. I already saw my own hack working in the demo ui of tinymail. It’s however done a little bit too gross to commit this hack somewhere.

But indeed, you click on a folder and the treeview starts getting filled up with headers while downloading is taking place. That, in the end, is what you spoiled users want. Right?

Well, on tinymail-based E-mail clients you will usually see this “fancy effect” only once. After that first time your folder’s summary will have a local state that doesn’t need a lot such changes to get synchronized.

Unless you added really a lot stuff using another IMAP client. And of course while the folder is active and you have a connection you will see the Push E-mail feature in action: new messages will be automatically added to the view too. This should give you the same fancy feeling! Whoohoo.

So that is what you can expect in a near future. This type of features might, however, be for a 2.0 release of the API. I don’t know yet. I’m a.t.m. too focused on coding to worry about releases.

A demo of the hack in action? No sorry, it’s late here in Belgium. Maybe tomorrow. It’s reusing a lot of the code of the Push-Email / IMAP IDLE feature. I posted a demo that shows that a few days ago.

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.

I have been doing some testing with the recent support for IMAP IDLE (RFC 2177) or Push E-mail using IMAP.

It might surprise people but IDLE is currently supported by most IMAP servers. I tested with Cyrus, Exchange, Isode M-Box, Courier and Dovecot. The only one that didn’t worked with the current solution in tinymail was Dovecot. I did see the right EXISTS coming through, it seems that the UID FETCH that follows gets wrong information. I really haven’t in depth looked at this though. So I’m not yet blaming Dovecot for this. It might very well be a discrepancy in how I’m using IDLE.

ps. I’m tracking the testing of IMAP IDLE & Push E-mail here.

Although it will need an enormous amount of testing, I just committed support for IMAP IDLE to the tinymail framework.

The by-the-server pushed summary information will be passed to the TnyFolderObservers of a folder. If you configured a TnyFolderMonitor to update your TnyList of TnyHeaders, which is usually going to be a TnyGtkHeaderListModel, then your view will also be automatically updated.

I created a screencast of the demo user interface where you can see this taking place.

Youtube version of the screencast.

You can use imap2.tinymail.org for testing. The server is also running Cyrus’s idled tool to speed up its IDLE notifications. Note that for now, only the Inbox folder has condstore-features enabled (sometimes, depends on my mood). You can remove and play with messages as much as you like. Under normal circumstances tinymail should update itself fully automatically not long after somebody does something (that’s what IDLE is all about: Push E-mail).

I would also like to note that fejj has restarted working on libspruce. Which is amazingly great news. I will most likely join sooner or later (as a warm-up I already posted some untested condstore code for libspruce, which I ported from camel-lite). And you can bet that once libspruce is usable, that tinymail’s camel-lite will be replaced with it. There’s still a lot of work for libspruce though.

Please note that this IMAP IDLE support is extremely experimental and will most likely deadlock and crash a few times. But then again, that’s just bugs. I mean, they’ll get fixed.

Important to know is that the observer / observable pattern being used by tinymail, can be implemented by any observer and by any observable in a flexible way. If tomorrow somebody implements a observable using SyncML (like me, as I’m nonetheless planning to also support it), then the tinymail API and design will cope with that. By the way, this is the design-idea page of all this.

It looks like GPE-Phone is using tinymail for their little E-mail application. I truly didn’t know that until this evening.

Ok, well. While I recommend waiting for Modest to read the code of an E-mail client that uses tinymail, or simply taking a look at the demo user interface, I guess this is good news.

A little clarification about evolution-data-server and tinymail.

About

Tinymail will not conflict, in any way, with evolution-data-server. The Camel in evolution-data-server is not, in any important technical way, “integrated” with the other components of evolution-data-server. If somebody once did integration with the Camel API part of evolution-data-server, exactly the same will still work with the embedded camel-lite of tinymail. That’s because the API has not changed (it’s true that some API has been added).

Tinymail also (by far) isn’t copying everything of evolution-data-server. It only contains the Camel part of it. And actually only those pieces of Camel that tinymail supports and uses (some providers have been disabled). It’s a size reduced one (and the size reductions are real). This means that tinymail users who don’t need other evolution-data-server components (and these users exist), are only using that exact specific part that is really used by tinymail.

One might think: then why isn’t Camel a separate library? From a technical point of view that is a very reasonable, sane and good question that I asked myself, too.

The camel-lite of tinymail has immensely changed. These changes are part of what tinymail is. Tinymail also depends on these changes. Not only did I change memory consumption, I also rewrote big parts the POP3 provider to support summaries and to make it possible to use it offline. I rewrote pieces of the IMAP code and I have recently added support for the condstore and binary capability. People are working on getting that upstream, indeed.

Getting it upstream

The speed at which these changes can go upstream is, however, not compatible with the speed at which the tinymail project is being developed. Although I’m trying to get as much upstream as possible, I also understand that some of the changes are very specific for mobile devices. It’s exactly those changes on which tinymail, naturally, depends the most.

API

The good part is that since only API was added, the only change that people who integrated with evolution-data-server using the Camel API have to make, is this one in their configure.ac:

- PKG_CHECK_MODULES(CML, camel camel-provider)
+ PKG_CHECK_MODULES(CML, camel-lite camel-lite-provider)

For mobile developers it’s also very easy to disable the camel part of evolution-data-server’s build environment. The building of Camel actually used to be disabled in the eds-dbus fork of evolution-data-server because not a single mobile application was using it nor was any of the other evolution-data-server components using it (and still isn’t as far as I know). The only thing you have to do is remove the word “camel” from the toplevel Makefile.am’s SUBDIRS variable. Although then you would have to make a small change to the tinymail build environment to compile tinymail, you could also copy the camel directory of tinymail’s camel-lite to that location.

A few weeks ago I wrote this official explanation on the subject.