[Kde-pim] Project proposal

[Volker Krause]

On Wednesday 25 March 2009 20:28:32 Ingo Klöcker wrote:
> On Tuesday 24 March 2009, Thomas McGuire wrote:
> > Hi Bertjan,
> >
> > On Monday 09 March 2009 22:17:37 BERTJAN BROEKSEMA wrote:
> > > As some of you already knew I will apply for a project at nlnet
> > > [1]. The main goal of the project will be to create/port/finish the
> > > mbox/maildir Akonadi resources, create a pop3 resource and create
> > > tests for the resources using Igors test framework. Attached you'll
> > > find a very rough first draft (most sections definitely need more
> > > work, especially the goals and activity sections). Any comments,
> > > questions, suggestions or even critics are appreciated.
> >
> > Although we already talked on IRC, here is a short summary so others
> > can read it as well.
> >
> > All in all, a good proposal, although with a lot of blabla in the
> > beginning, but I suppose that is needed for applying :)
> >
> > Now to the mbox resource: It would first create a mbox library, so it
> > can be shared, like the maildir library. For example, kmailcvt, the
> > mbox ioslave (who the hell uses this one!?),
>
> It was used by korn IIRC.
>
> > or even old KMail could be converted to use it.
> >
> > Then I would base an mbox resource on top of that library. Well,
> > actually I would create a resource that can handle a mixed tree of
> > maildir and mbox, because we need that anyway, for backward
> > compatibility. Similar to what the "Local Folders" project proposal
> > does.
> >
> > Also we said that POP3 should be an agent that fetches mail and puts
> > them into Akonadi folders, e.g. a maildir folder. It should not be a
> > resource, or at least not act as one. Rational is that POP3 is really
> > for fetching only (even the RFC says that), and not a resource fit
> > more into the usecase of something with a real storage behind it.
>
> Hmm. What about functionality like "fetch only headers" and "fetch full
> message on demand"? Also, if POP3 is an agent then POP3 filtering
> probably will still need to be special code. If POP3 is a resource then
> POP3 filtering should be doable the same way as other filtering.

Right, and special code would also be needed for resource selection, manual 
and interval mail checking, etc. IMHO more than enough reasons to make POP3 a 
resource as well. As I have discussed with Thomas on IRC recently, we can 
then still emulate his use-case (full fetching into a folder associated with 
a different resource). This might require minor changes to Akonadi code, but 
still much less work than special-casing POP3 in every mail application.

As this topic keeps coming up, I've put it on the agenda for the meeting next 
week, we finally need to resolve this ;-)

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/20090326/7a7b9075/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/