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

[Volker Krause]

On Sunday 03 May 2009 16:40:29 Thomas McGuire wrote:
> Hi,
>
> On Sunday 03 May 2009 01:02:38 Tom Albers wrote:
> > > * 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?
> >
> > Single resource, two folders imho.
>
> +1
>
> > > * 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?)
> >
> > Yes, it has nothing to do with kmime and it is a resource so the
> > kdepim/akonadi/resources makes a lot more sense to me.
> >
> > I don't think the inbox needs to be in this specialised resource, the
> > power of akonadi is that it seperates all this functionality, let's not
> > polute it. Mailody does not need an Inbox there. I would vote for a
> > separate pop3 resource which might link in the items from the outbox or
> > sent-items if the application uses that.
>
> Ok, I think there is a misunderstanding how how I imaginged what the
> "LocalFolders" class is. The LocalFolders class is _not_ a resource itself.
> It is just a convenience class that will create a maildir resource (if it
> doesn't exist yet) that points to ~/.local/share/mail and sets up the
> outbox and sent-mail collections if needed.
> It would then provide methods to return the collection id of those folders.
>
> Because the LocalFolders class is very much mail specific (it only creates
> mail folders), I would indeed put it into kdepimlibs/kmime.
>
> Since it already creates a outbox and a sent-mail folder, it would also be
> a logical place to create an inbox folder as well. If nobody calls the
> inbox() method that returns the collection id of the inbox, the
> LocalFolders class would not tell the maildir resource to create that
> folder, and therefore we would not pollute the folder tree with an inbox if
> that is not needed.
>
> I would like to use this inbox() method in the POP3 resource.

IMHO there is no such thing as "the inbox" or "the sent-mail folder". Eg. one 
inbox per POP3 account looks like a better default to me than putting 
everything into one folder. And for sent-mail we already have various ways of 
selecting a different destination.

So, such an API would merely provide fallbacks, in case nothing is configured 
(it needs to be async anyway, so no simple inbox() call). Still, this is 
something we might indeed want convenience API for (although not limited to a 
few special folders) as this is a common scenario for error handling in 
resources: if an object could not be stored remotely due to a non-transient 
error (eg. lack of access rights), it is put into a local lost+found 
collection (see eg. KMail's IMAP code).

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