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

[Volker Krause]

On Sunday 03 May 2009 00:35:37 Constantin Berzan wrote:
> 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?

The outbox does not necessarily need to have a "physical" representation in 
form of a maildir. As it contains only temporary data anyway, it could just 
as well only exist in Akonadi (that is currently not yet possible, as Akonadi 
enforces a resource ownership for every collection, but that will eventually 
change).

> * 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?

Mailtransport has a default transport, which could be used in this case.

> * 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.

There is also a capabilities field for resources which can be queried via 
Akonadi::AgentType. That could be used for discovery as well.

The D-Bus interface would also needs a way to report success/failure and 
possibly status information.

> * 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.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090503/046571a9/attachment.sig>
-------------- next part --------------
_______________________________________________
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/