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

[Volker Krause]

On Sunday 03 May 2009 17:44:06 Kevin Krammer wrote:
> 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.

How would resources report results (success/failure) back to the dispatcher 
agent? Or would they do the final move to the sent-mail folder themselves?

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/20090504/9a40e4f4/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/