[Kde-pim] Akonadi outbox & dispatcher agent [tentative design]

[Constantin Berzan]

Hi all,

Based on last week's discussions on IRC, here is an outline of how we plan to 
implement the global outbox with Akonadi.  (I'm doing that for my GSoC [1].)  
I am sending this email so that those who have taken part in the discussion 
can correct me if I misunderstood their points, and so that others can chime 
in as well.

[1] http://lists.kde.org/?l=kde-pim&m=123837257902211&w=2

Background:
* The mailtransport lib currently provides a combo box with a list of 
transports.  The transport type is uniquely identified by its index in this 
combo (TransportComboBox::currentTransportId()). This is convenient for 
applications and we want to keep this.
* The mailtransport lib is currently able to send email using SMTP or sendmail 
(these are built-in).  Additionally, the nntp, groupware(?) and openchange 
resources implement their own protocols for sending email, and we don't want 
to duplicate that.
* After sending messages, KMail puts them in a sent-mail folder. We want to 
keep that concept.

Design:
* The outbox and send-mail folders will be maildirs on the local machine (e.g. 
in ~/.local/share/mail/{outbox,sent-mail}).  Does it make sense to have two 
separate resources (outbox and sent-mail), or a single resource managing both 
these directories?
* Applications can put messages in the outbox collection.  If this is done via 
Akonadi, then the items will already have a send_with_transport attribute.  If 
not (e.g. a plain file is created in that maildir), then should the dispatcher 
ask the user for which transport to use?
* The dispatcher agent will monitor the outbox collection, and when it finds a 
new message there it:
- passes it to mailtransport (see below)
- when/if sending has succeeded, moves the message to the sent-mail 
collection.  If the message contains a special 
after_sending_move_to_collection attribute, move it to that collection instead 
of sent-mail.  (This last bit is useful for things like keep-replies-in-
current-dir).
* mailtransport needs a way to find all the resources (like groupware) that can 
send mail.  Resources could provide dbus methods like canSendMail() and 
sendMail(msgID), and mailtransport can query each of them and if it 
canSendMail then put it into the combo box.  When asked to send a message 
using one of these transports, mailtransport simply calls the appropriate 
method for the appropriate resource, passing it the ID of the message in the 
outbox collection.
* A LocalFolders class takes care of creating the outbox and sent-mail 
collections for the first time, and can be used later to access these 
collections.  It will also have an Inbox folder for POP3, but that is 
unrelated to this project.  The class will reside in kdepimlibs/akonadi/kmime 
unless someone suggests a better location (perhaps in kdepim/akonadi/resources 
somewhere?)


That's it.  I'm sure plenty of issues will show up at coding time, but if you 
can foresee some now, comments are appreciated.

Thanks,
Constantin



-- 
http://ascending.wordpress.com/


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/