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

[Thomas McGuire]

Hi,

On Sunday 03 May 2009 11:40:00 Ingo Klöcker wrote:
> On Sunday 03 May 2009, Constantin Berzan wrote:
> > 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?

I think the transports are indeed identified by UID, so no problem here.

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

I think we should create the sent-mail folder only when really needed (when 
not using IMAP), but have it in the same resource.

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

We can also add the identity UID as an attribute to the mail in the outbox. 
The mail dispatcher agent can then use the kpimidentities classes to get the 
identity and its sent-mail folder. But then we also have folder overrides 
(keep replies in this folder), so this identity approach would not work.
I think we should go the after_sending_move_to_collection way, this attribute 
can be created when some convenience API moves the KMime::Message into the 
outbox. The attribute would depend on the identity passed to the API method 
and maybe some folder-specific settings.

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

As Volker said, we want to keep the mailtransport UI elements like the 
transport combo box and other concepts.

Regards,
Thomas
-------------- 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/dc5f80c2/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/