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

[Ingo Klöcker]

On Sunday 03 May 2009, Volker Krause wrote:
> On Sunday 03 May 2009 11:51:41 Ingo Klöcker wrote:
> > On Sunday 03 May 2009, Volker Krause wrote:
> > > 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).
> >
> > That would require all apps that want to send mail to depend in
> > some way on Akonadi. OTOH, if there is a physical outbox then such
> > an app only needs to depend on some message composer library and
> > then it could simply drop the composed message into the physical
> > outbox. I'm not sure whether this workflow is really necessary.
> > Alternatively, to dropping the message into the outbox it could
> > probably also run a helper app which puts a file into Akonadi's
> > outbox. *shrug*
>
> I'm wondering if the additional overhead and complexity of a
> monitored maildir outbox is worth the effort though. After all, when
> relying on the mail dispatcher agent there is a runtime dependency on
> Akonadi already anyway.

Right. OTOH, the maildir resources anyway need to monitor the maildir 
folders for new messages so that people can finally use procmail and 
friends with KMail without having to jump through several loops. It's 
also needed for the user's mail spool (although this one is probably in 
mbox format).


> Having a command line tool for sending mails makes probably sense, in
> fact we have one already (ksendmail), which currently relies on
> KMail.

Yeah, that was what I was thinking about.


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