Category: Informatics and programming

Let’s make a GNOME OCR application on top of Ocropus. One where the user can select regions to scan for text and where those regions will translate to XHTML DIV tags that are relatively positioned right and where the user can select regions to simply copy as image. Doesn’t sound terrible hard, or does it?

After that, let’s rethink some of the printer uis and dialogs and/or integrate it with SANE a little bit: a lot of printers nowadays are so called ‘multifunctionals’: they combine a flatbed scanner with a printer and have fancy features like: scan to your computer, scan to a MMC card, scan and print (make a copy).

It’s a little bit silly that I right now have to scan to an MMC card, put that MMC in my N800 because Linux doesn’t support the MMC slot of my Laptop, wire things up with USB cables, copy the a file called SCAN0016.JPG to a folder, open it with GIMP and dissect it into regions and do other conversions to the image that might improve OCR detection, manually create an xhtml document and manually measure the positions on the original, manually put that into relative positions of the xhtml file, etc etc. I mean, these are all tasks that can easily be automated.

And now we finally have a reasonable good OCR library or framework as underlying engine for this.

I’m sure Google would love projects like this for their Summer Of Code, for example. No?

Anyway, the Google Ocropus thingy works on most normal texts. I just printed out a few documents with also some handwritten names and signatures on, scanned the prints in and did a OCR scan on the scans. The handwritten parts caused some discrepancies in the detection, but the vast majority of the text got detected right. With maybe a few a-s that turned into o-s (well, that document’s font was quite hard for those two characters indeed). I’m quite sure the library will improve.

The getting started page talks about going into a release directory, right? Well, the page isn’t very clear about it (yet): you need to get both tesseract-ocr and ocropus itself (which is explained in the “Downloads” tab of the site). That release directory is your “ocropus” Subversion checkout, it seems. Well, that worked for me. You’ll also need to install jam, libtiff4-dev, libaspell-dev. All the other stuff was already installed on my typical “gnome-devel”-prepared Edgy.

Sergio Villar gave me his Guademy presentation about tinymail.

It’s in Spanish. If somebody makes a translation: send it to me (or to Sergio) and I’ll put it online.

Update: English translation by Arien.

Oh, I’m also back from Paris (fostel) yadi yada. It was very interesting and highly technical (which is the way I like conferences). I met a lot of very interesting people too. Guess I will be answering my E-mail of last week tomorrow.

I started a little sub of the tinymail project called TMut. It will implement a minimalistic E-mail client for, for example, mobile phones.

Although minimalistic, it will become a functional E-mail client. It will function as a basis for building on top of and as a potential usable client for your mobile.

TMut will help proving that tinymail scales to both larger projects like Modest, as that it scales to smaller E-mail client projects for mini devices like mobile phones, smaller PDAs and VoIP phones.

Although it’s not doing anything right now, all of the minimal tinymail components have already been put in place. I of course need my focus on tinymail itself, so I don’t know how fast this will be ready for use. A minimal E-mail client can be done quickly with tinymail, it should therefore be functional soon. And if not, doing TMut will be a good exercise for me to find the difficult spots and the things that need more documentation in the API.

Because I want TMut to be as language neutral as possible, I will be doing it in GObject with C. Mind that TMut is also going to play the role of a tinymail demo that is more functional than its current demo ui. I’m guessing people who’ll build their own client on top of tinymail want as few decorations as possible. Maybe they will inherit from the TMut types in stead of starting from scratch? Doing TMut in a specific language might limit the options for such teams.

Note: I updated this page on the tinymail ‘marketing’ pages. If any of the projects mentioned on the page want a different description and or prefer to be removed from that list, get in touch with me. If you are starting a project that uses tinymail and want to be listed, you can of course also contact me.

The majority of the bugs of that “it’s still a little bit buggy” quote of my last blog entry where caused by “gtk_tree_model_row_inserted” happening outside of the mainloop thread.

This has been fixed now, and since revision 1750 will the demo user interface utilize the feature.

Tinymail based mail user agents can therefore, like Dave’s excellent Polymer and Telomer, immediately start showing your summary while you are downloading it (not only after it finished downloading it).

With the Push E-mail support you will on top of that receive changes like incoming and deleted E-mail. Mail user agents based on tinymail can easily act on those events by updating the summary view’s model using build-in tinymail machinery (as this demo shows).

It’s also possible to know the X-Priority flag and soon it will be possible to have the message’s bodystructure upon those Push E-mail events. This will make it possible for your mail user agent to select ring tones based on this information. For example if your boss has send you an urgent meeting request, the mail user agent can launch a different ring tone.

And since you can base these decisions on more information than what SMS and MMS messages offer, I just gave the “big guys” at Nokia & co. a new feature for selling new phones! Tagging messages. I know, I know, I’m being naive by thinking that phones will someday ship with tinymail. Who knows? With tinymail, using folders of 10,000 messages fits in ~ 4 megs of RAM: modern phones have this amount of RAM already.

A big problem will of course be that SMS & MMS are more profitable than GPRS for the current mobile operators. I’m quite sure that will be an issue for “E-mail on phones” in stead of “SMS & MMS”. Let’s hope the Steve Jobs’s of our world will show those guys what today’s people really want.

These features need testing of course. They also need a real mail user agent to get fully fleshed out. People are today building one, but don’t let that stop you from creating your own mail user agent on top of tinymail. Although their project is about policy and although that policy might not be in line with your ideas, maybe you can join their team? Encourage them to design that policy in a flexible way?

They are your dreams. I’m building the framework to support them.

I implemented letting the tinymail demo user interface fill up its summary view while downloading summary information. I, of course, created a little demo for it too.

I haven’t yet committed the work on this in tinymail’s repository, because it’s still a little bit buggy. You can expect that I will have this finished by the end of this weekend, though.

Youtube version of this movie

The folder monitor stuff of Modest needs some adaptations to leverage this new feature fully in that mail user client. I might take a look at improving Modest so that it too will immediately start displaying the headers while they are being downloaded.

I forgot to mention this, but iRex Technologies has released their source code and adaptations.

From talking with them at T-DOSE and FOSDEM, I have understood that they can use our community help in getting them to understand how to form a healthy win-win relationship with us. I hope the do-people of our community will contact them (for example at the various conferences) and guide them a little bit. I’m sure that this is learning for both sides: we need to understand how technology companies work and what they really need. They need to understand us and about our licensing ideas and ideals. Although I think with Nokia’s Maemo & OpenMoko at least the GNOME community seems to be getting it (like picking LGPL rather than GPL for libraries). Liking the GNOME platform myself, I’m of course biased.

My own personal guideline for this is: do they have the right intentions and are they just struggling to get there? Or do they have the intention to simply steal our work? There’s a huge difference in my opinion.

They had some legal struggles in the past it seems, which I think isn’t abnormal given that they are developing on top of a lot of new technology. It looks like they have the right intentions with our ideals, softwares and licensing. They have a real ePaper device that already and actually works. I’m sure they need quite a lot adaptations to our platforms and application software for the device itself. Why not show that the people who are involved with free software on desktop & mobile are a community of people who are serious with technology companies who want to support their own expertise by leveraging our softwares?

These times are our slot, let’s not miss it again. In general: if you have ideals about software development: please think “do”, not just “talk”. At least that’s my opinion.

I finished wrapping the API launchers of tinymail‘s core abstraction library (libtinymail) with require and ensure sections, like Eiffel’s design by contract clauses. Unlike in Eiffel you can’t weaken them in tinymail, you can only strengthen them. I didn’t use nana or ‘DBC for C’ for this, just assertions that wrap the function pointer invocation of the interface’s class struct.

The benefit is that it’s not in the body of the implementation, but rather at the interface’s level: If DBC is enabled and your implementation doesn’t fulfill the ensure clause, then the application will abort. To put it in another way: all implementations must fulfill the full contract of the interfaces that they implement. Also must the client code that uses the interface fulfill the requires clause. So any client code that calls an API yet doesn’t fulfill the input contract, makes the application abort itself (if DBC checking is enabled).

As usual, I try to practice what I preach, here’s the documentation on both using the contracts (enabling the checks) and creating your own ones while doing development for and with tinymail.

WordPress’s Dashboard notified me of this blog item of an Isode employee about tinymail, Modest and Lemonade.

Totally impressed by the language support for design by contract in Eiffel and in total agreement for the need for build-in support for this in modern higher programming languages (like what Eiffel clearly is), I decided to go for the idea and therefore I just started instrumenting all the interface method launchers of tinymail.

Maybe other people have better ideas for this with GObject and C? Please do contact me, as I’m truly interested in fully instrumenting tinymail with DBC contracts for all its interfaces. I started with the TnyDevice one. Interesting are the tny_device_force_online and tny_device_force_offline methods. They must ensure hat the result of the tny_device_is_online query will be either true in case of forcing online or false in case of forcing offline.

Any implementation of TnyDevice that doesn’t do this, is wrong. Since TnyDevice is implementable by the platform specific developer I want to know about their bugs without having to look at their code. Basically making it possible for me to say: look, run this suite and if you have assertions, it means that your implementation is broken. Fix it and come back.

I know that sounds harsh, but application developers whom I’ll ask to implement something will in stead be grateful for these contracts: they’ll very quickly know where there’s a bug in their own code.

Don’t go search the code for Design By Contract assertions yet. I’m adding them right now. You can of course join me on IRC: #tinymail at GimpNET.

It’s not yet accepted but it looks like Dirk-Jan proposed doing a little chat about Modest at Guadec this year.

I figured it’s going to be a tinymail related presentation and maybe, who knows, will others do talks and presentations on the subject in future too? Although I might improve the location by giving it an actual page like the demos page, you can already find my own slides there. I left out the FOSDEM ’06 one as that one was about software design with GObject, not about tinymail. The FOSDEM ’07 one was about tinymail, so it’s available.

Oh .. I might be interested to do some marketing around tinymail. Nothing big though. I’m not sure yet: once Modest and other E-mail clients start getting used, it might automatically sell? Maybe marketing is overkill? The project might not be mature enough? Perhaps it’s just a bad idea? Perhaps it’s a great idea? I also don’t think there are a lot competent marketing people who understand free software (except for two crazy Australians, though that’s not marketing but rather ‘strategic consultancy’, right?).

Boy, it should be clear by now that I truly lack experience in leading a project. The idea of “leading a project” also scares the hell out of me. Given that I’m actually quite incompetent at some important social skills. Well, Daniel Coleman writes in his books about emotional intelligence that being self aware helps a lot. So I’m not fully incompetent! :-). At least one contributor actually wrote on his blog that he’s happy. I’m proud of that achievement! I never thought I could do that through a project (you know, making people happy).

Now these Subversion guys tell us, project leaders, that we need to be careful of both poisonous people and even of not becoming poisonous ourselves. I mostly agree with the end of their presentation (not with everything): that you need to be very careful with quickly identifying people as poisonous.

Over time a lot projects start consuming rather more than less memory. Mostly it’s not due to the added features themselves. Often it’s rather due to the amount of code growing and maintainability getting harder. A result is often that the good ideas and great ideals about memory consumption fade away a little bit.

I disliked that strategy from day one for the tinymail project.

Also note that most of the times just throwing more into ram, does not necessarily mean that your application will perform better. Often the exact opposite is the case: because it’s often due to your design being broken. Most hacks are just what they are: hacks. Most hacks are in reality slowing down things too.

I made the decision that I will design in a flexible and adaptive way starting day one. This means that new features have always been easy to add to the framework, cause of its design. It’s a misconception that good design automatically means a lot memory consumption. In fact, the contrary is often true. It’s also a misconception that you can’t use C for this. When designing, the programming language is mostly irrelevant. Although D is indeed a kick ass programming language :-) (boy, it feels good to say subjective crap in my blogs. Moeha!).

I remember the days when I flooded my own blog about how tinymail was only consuming something like say ~18MB of heap allocations for displaying a folder of 50,000 items. Well, I have improved that figure a little bit. Today tinymail consumes 8,613K when displaying a folder of 50,000 items, with a ~10MB mmap (which hasn’t significantly changed since).

I made a new memory report which is available on the trac. I added quite a lot documentation about mmap, about how tinymail uses the memory and about the slab allocator. I did this to make sure that people who’ll be really reading the report will have as few misconceptions as possible.

You can of course reproduce the report and all steps for reproducing it are documented too.

Imagine you just created a nice GObject with a so called “priv thing” in it. Yes, “thing” is a good name for now. In your code you access that “priv thing” using the G_TYPE_INSTANCE_GET_PRIVATE GType “stuff”. Most of the time you are a happy hacker with a “priv thing”. Then suddenly you have a bug somewhere in client code of that GObject type of yours (by client code I mean: code that is using an instance of your type, like calling API on it).

You’ll most likely want to peek at that “priv thing”? Doesn’t sound very unusual, right?

Well it’s actually quite simple:

We have a GtkTreeModel, which is a GTypeInterface implemented as TnyGtkHeaderListModel. The instance of that TnyGtkHeaderListModel is called “self”. The instance (which in this debugging session plays the role of the client code for a TnyFolder instance) will do some stuff with another instance stored at self->folder. With some casting voodoo magic we can easily get the “folder” instance out of that. Nothing difficult here.

Let’s do this step by step …

(gdb) print self
$17 = (GtkTreeModel *) 0x82f8090
(gdb) print *self
$18 = <incomplete type>
(gdb) print ((TnyGtkHeaderListModel*)self)->folder
$19 = (TnyFolder *) 0x8253ba8
(gdb) print *((TnyGtkHeaderListModel*)self)->folder
$20 = <incomplete type>
(gdb)

We are after the “priv thing” of that folder instance: we’re not there yet. But let’s dig a little bit deeper!

(gdb) print * (TnyCamelFolder*) ((TnyGtkHeaderListModel*)self)->folder
$21 = {parent = {g_type_instance = {g_class = 0x80e0b98}, ref_count = 2, qdata = 0x0}}
(gdb)

We’re still not there, and we still haven’t even seen a sign of that “priv thing”. That’s because it’s somewhere deep inside the “crazyness” of the glib GType stuff. Don’t worry, we have yet another gdb trick as tool in our pocket. We can actually launch some of our own code. Including code from the glib library.

(gdb) print g_type_instance_get_private (((TnyGtkHeaderListModel*)self)->folder, tny_camel_folder_get_type())
$22 = 136657848
(gdb)

Okay, let’s not care about the number and just use that $22 label.

(gdb) print *$22
$23 = 1
(gdb)

Well…of course! Our beloved debugger doesn’t know how that pointer looks like! Let’s tell it. Because “we” .. know, right?

(gdb) print *(TnyCamelFolderPriv*)$22
$24 = {loaded = 1, headers_list_type = 0, folder_changed_id = 132, headers_managed = 1898, folder_lock = 0x826af80, folder = 0x81f7868,
  folder_name = 0x826afb0 "INBOX/30000", account = 0x80e58f8, store = 0x80e5a08, cached_length = 1898, unread_length = 49, unread_sync = 0,
  local_size = 258652, subscribed = 1, has_summary_cap = 1, iter = 0x81f6800, iter_parented = 1, cached_name = 0x826afc0 "30000",
  cached_folder_type = TNY_FOLDER_TYPE_NORMAL, remove_strat = 0x820a8b0, receive_strat = 0x820a6a0, observers = 0x8259fb0,
  sobservers = 0x8259fc8, self = 0x8253ba8, want_changes = 1, dont_fkill = 0, parent = 0x81f3ee0}
(gdb) 

Maybe we should make some gdb-shortcuts and do some integration with gdb and glib? I do like things like refdbg and I like all those other tools too. Yet I still have to fall back to using gdb most of the times.

Let’s play some more, digging deeper:

(gdb) print ((TnyCamelFolderPriv*)$22)->folder
$25 = (CamelFolder *) 0x81f7868
(gdb) print *((TnyCamelFolderPriv*)$22)->folder
$26 = {parent_object = {klass = 0x82a9130, hooks = 0x82f9190, ref_count = 1, flags = 0}, priv = 0x8216e00, name = 0x82f75f0 "30000",
  full_name = 0x825d4f0 "INBOX/30000", description = 0x0, parent_store = 0x80e5a08, summary = 0x80b8368, folder_flags = 3,
  permanent_flags = 8194079}
(gdb)

(gdb) print *((TnyCamelFolderPriv*)$22)->folder->parent_store
$31 = {parent_object = {parent_object = {klass = 0x80de0e0, hooks = 0x80bca80, ref_count = 7, flags = 0}, priv = 0x80e55e0,
    session = 0x80b9c00, provider = 0xb6233da0, status = CAMEL_SERVICE_CONNECTED, connect_op = 0x0, url = 0x80e6230, data = 0x80e5ba0},
  priv = 0x80e5778, folders = 0x80e57a8, flags = 11, mode = 3}
(gdb)

Modest’s source code hasn’t been available for more than a week, and it is already supporting Push E-mail. I created a little video demo showing this feature.

We of course have Modest running on our Maemo devices, like the Nokia 770 and the N800. The Push E-mail feature works on the device too. You can expect video demos of Modest running on the device soon. For packages you will have to wait: we want to make sure that it’s rock stable and really works well.

Modest and the tinymail demo-ui showing Push-Email

Youtube version

Some notes: If you are going to experiment with your own Cyrus install, then make sure that you have the idled daemon of Cyrus running. You can also use these test IMAP servers for experimenting. They all support IMAP IDLE (therefore they support the Push E-mail of both tinymail and Modest). The Cyrus one also has condstore turned on on its INBOX folder, which is another Lemonade enhancement that you might want to test with.

I would like to stress that tinymail nor Modest have had intensive testing. Please don’t yet use it on real accounts unless you really don’t care about losing your E-mails and data. I try very hard to make sure that you do have testing infrastructure. You don’t have to test tinymail or Modest with your own accounts.

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.