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

[Kevin Krammer]

On Sunday, 2009-05-03, Thomas McGuire wrote:

> I would keep them in once resource, otherwise we have so many processes. We
> can create those folders (and maybe even the resource) on-demand, so that
> the folders are not created when not needed.

You will only need one for sent-mail if you don't want that to be a folder of 
another maildir resource or an IMAP resource.
Outbox might not even need a local on-disk representation, see Volker's 
suggestion.

> > > * 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?
> >
> > Or one "out" directory for each transport
>
> For my own use, I prefer one directory, otherwise the folder tree is too
> cluttered with outboxes. Could be a configure option if someone _really_
> prefers multiple outboxes.

I was not referring to folders generally I was specifically referring to 
directories.
The dispatcher agent could watch any number of directories, one associated 
with a special transport.
Only applications which want use the "drop mail as a file" feature would use 
those directories to send mail.

> > How about having a special collection attribute for marking such
> > collections?
>
> Don't understand what that is needed for. Mailtransport already knows the
> id of the outbox collection and the id of the messages in it, and only
> passes the item ID to the nntp/groupwise/etc resource, which should be
> enough for the resource to handle the sending.

Right.
I was thinking about a different worrkflow, i.e. the dispatcher moving the 
mail to the outbox of a resource and the resource then handling the mail 
however it would like to.

Kind of like communicating on collection level, not on explicit D-Bus call 
level.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

-------------- 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/fbf0433a/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/