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

[Ingo Klöcker]

On Sunday 03 May 2009, Constantin Berzan wrote:
> 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.

Huh? An index in a combobox is surely not invariant in time. If a 
transport is deleted then some indexes will change. I thought the 
transports would be identified by a (G)UID?


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

In Osnabrück some people mentioned that for some groupware servers 
certain "messages", e.g. replies to invitations, need to be handled 
differently from normal email messages. So there should probably be a 
message_type attribute depending on which a sending ressource would 
decide how to send the message. The dispatcher agent probably doesn't 
need to worry about this detail.


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

I'm with Kevin on this one. People with a single IMAP account will have 
no use for a local sent-mail folder.


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

I'd make it configurable:

  Use the following transport for messages without specific transport:
    [ ] Use default transport
    [ ] Use transport [<transport combo>]
    [ ] Ask me.

It should default to "Use default transport". This will make it work 
out-of-the-box for users with a single account.


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

Similar to the above I'd make this configurable:

  By default put sent messages into the following collection
    [collection selection]

A sensible default would probably be the sent-mail folder defined for 
the default identity, but identities are probably not known to the 
dispatcher agent. ???


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

I'm not sure why the indirection through mailtransport is needed. I 
would have thought that the dispatcher agent would talk to the 
appropriate resource. mailtransport would then only be used for the 
standard transports SMTP and sendmail. This would keep mailtransport 
(as low-level library) independent of Akonadi.


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

I'm with Tom on this one. Put it into kdepim/akonadi/resources (or 
agents ?).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090503/1c7c151f/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/