Re: The new TnyCamelSendQueue

[Philip Van Hoof <spam pvanhoof be>]

I added a .zargo (ArgoUML) and a PNG export of it to this page and I
enhanced the diagram a little bit (i.e. by adding comment boxes which
should explain/illustrate the missing information of this design or
concept)

http://tinymail.org/trac/tinymail/wiki/HelpDesignCodingSendSupp

http://tinymail.org/trac/tinymail/attachment/wiki/HelpDesignCodingSendSupp/sending_mails_tinymail.zargo
http://tinymail.org/trac/tinymail/attachment/wiki/HelpDesignCodingSendSupp/sending_mail_tinymail.png


On Thu, 2006-11-16 at 21:36 +0100, Philip Van Hoof wrote:
> 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