Yes me shall.
Most E-mail clients want some sort of queuing mechanism. Not surprisingly every developer has the desire to implement his own queue thing. This by itself is not a big problem if only they create a wrapper for their queue that implements my interface.
After that, I have some guarantees about that implementation that I can use to develop higher level functionality. Guarantees like the availability of a specific certain API. I need to fine tune the Design By Contract clauses for this little bit more, but these queue interfaces are well documented and by-contract defined (or going to be even more strict).
A few months ago I announced this AsyncWorker thing. A normal person would maybe simply require that library and assume that all developers will bend over and let me put my AsyncWorker … where the sun doesn’t shine? That’s not Tinymail’s concept though: flexibility and being adaptive to Change is.
Although I added a libtinymail-asyncworker library that implements a default queue implementation, you can implement your own. I believe a lot E-mail clients will actually want to do that: maybe they want very tight integration with and a lot of control over their queue? I can imagine that.
The trick, though, is to build a bunch of standard queue functionalities yet make it possible that they all share the same top level queue. For that, I used the decorator design pattern. All the default queues, except the asyncworker one, implement the queue interface and will aggregate one too. Usually that will be a base queue implementation, like the asyncworker one, but it can also be any of the queues (nested situations, why not).
I’m starting with a queue that will in the background get full messages, one that will act right after a full message is received and one for sending messages.
The one that will act will for example (depending on your mua’s policy) share a top level queue with the one that gets full messages in the background. It will have tasks with a higher priority though: acting can for example mean “to display that message in the message view”. While perhaps messages are being queued for retrieval? While Push-Email events cause get-message tasks to get added to the queue?
The thing is, Push-Email right now will only get the summary info of a message. But if that Push E-mailed E-mail contains a calendar item, then you’ll need to fetch that if your application wants to do something interesting with the calendar content. Like playing a different ring-tone if it’s a calendar item coming from your boss? Your application can in that case use a queue that will act with something, right after the queued task received the full message.
You guys remember that Push E-mail events can be caught using a TnyFolderObserver, right? An implementation for your folder observer’s update method could be “put a task on the act queue that will add the calendar item in the E-mail to the device’s calendar” once the task finished receiving the message. That is already possible with Tinymail today, yes.
I’m writing documentation right now. A bunch of it is already available, but the best page to start is this one: TnyQueue and TnyQueueTask. I need to adapt my gtk-doc scripts to enable adding the API to the API reference manual of Tinymail. All of the API is already documented fully, though. The script just isn’t yet adding it to the gtk-doc build.
Note: that some other E-mail clients don’t have this amount of flexibility for queuing just means that they are too limited for mobile applications. Mobile applications need to cause events to wake the person up. I believe that Push E-mail is just the beginning of all this. Future will tell, of course.
And Tinymail will be ready for that.