The new TnyCamelSendQueue

[Philip Van Hoof <spam pvanhoof be>]

I added a first dumb implementation of a TnySendQueue. This is one of
the features that people are paying me for.

Currently it's a dumb implementation because it doesn't persist the
to-send messages on disk. For example in a so-called Outbox folder.

This is of course the idea. For now it's implemented using a dumb doubly
linked list in memory.

The current idea is to let each TnyTransportAccount, by interface, have
a few TnyFolder properties like Outbox, Sent and Drafts.

The idea here is to let those instances be sharable between different
account instances. This can means that TnyTransportAccount will also
implement TnyFolderStore (just like the store account types currently
also do).

With sharable I mean that two transport account instances will return
the same TnyFolder instance when for example asking for the Outbox
property.

There's nothing strange about that, of course. Except that this means
that the locking when adding & removing a message to or from that folder
must be in the TnyFolder, and not in the TnyTransportAccount nor like
now in the TnySendQueue. (this is extremely important, indeed)

It's also possible that there are multiple different Sent, Drafts and
Outbox folders per each transport account. Why not (I have this type of
setup on my own Evolution).

It's, however, the application developer who should define this. For
example by setting the properties of the transport accounts.

Sounds fair? Yes? No? Thoughts? Code? Contributions? People who want to
join coding this? 

Once this piece of code is accepted by ***** (you know who) I might even
pay the real contributors who helped me with this. My accountant,
however told me that bounty-style is very difficult unless I want to pay
a lot tax on whatever I'll give you for your contributions. So I prefer
self employed people and/or companies (so, for financial reasons. not
because I'll dislike you if you are not self employed), unless you can
offer me good solution -- or are willing to get less because I will have
to pay something like 50% tax on this sponsoring/gift.

Hmm, maybe I shouldn't make too much promises. Let's first code it, get
it accepted and then see what we can do (also for future such features
and enhancements -- there are plenty asked-for).

SO, what has to be done:

   o. Let TnyTransportAccount implement TnyFolderStore and make sure
      that all the interface's methods are correctly implemented (get
      folders would put three folders in the TnyList instance that is
      passed byref)

   o. Add three properties "outbox, sent, drafts"

   o. Create a Maildir standard implementation in libtinymail for
      TnyFolder with VERY correct and CHECKED locking for adding and
      removing a message. Camel has a Maildir CamelFolder that you can
      wrap for this (you lucky bastard!)

   o. Let TnyCamelTransportAccount's default outbox, sent, drafts
      properties return such instances (located in the Camel cache
      folder, in a subdirectory that is unique etc etc)

   o. Adjust TnyCamelSendQueue to now use the outbox and sent properties
      of the TnyTransportAccount that is uses to send E-mails with. 
      Adding on the add method and moving it to sent when the queue has
      sent it. In a more or less transactional correct way, with correct
      locking. PEOPLE DON'T WANT TO LOOSE E-MAILS WHATEVER HAPPENS, will
      CONSTANTLY be on your mind while coding this.

   o. A bunch of unit tests that test all this


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog