[Kde-pim] gsoc project: akonadi for pop3 and smtp

[Ingo Klöcker]

On Tuesday 24 March 2009, Thomas McGuire wrote:
> Hi,
>
> On Tuesday 24 March 2009 03:46:14 Constantin Berzan wrote:
> > On Monday 23 March 2009 18:37:19 Thomas McGuire wrote:
> > > Right now, it is quite unclear who does which project,
> > > unfortunatley. I think Bertjan dropped doing POP3, so that would
> > > be available.
> >
> > Indeed, I emailed Bertjan and he told me I could do POP3, since he
> > would focus on another project.  However, after discussing the
> > composer thingy, I am much more excited about this than about POP3
> > :)
> >
> > Attached is a draft proposal for separating the KMail composer and
> > porting it to KMime.  If you could read it and point out flaws,
> > that would be great.  I haven't looked at the code very much yet.
> >
> > > I think you can basically pick a project of both, or even submit
> > > two proposals.
> >
> > For now I put pop3 and the mail dispatcher agent as "optional
> > goals" for the composer project.  I am reluctant to write another
> > proposal since I already have a second proposal for a KWin idea
> > (it's by far my second choice though). Another reason is that I
> > will try really hard to leave enough time for the mail dispatcher
> > thing, because it gives us a global outbox which rhymes very well
> > with the standalone composer.

Exactly. I'd even go as far as calling the mail dispatcher agent a 
prerequisite for a standalone composer. Without the dispatcher the 
standalone composer would still need a running KMail/KNode for sending 
(since sending does not belong into the composer IMO).

A variation of the project I can think of could cover the following 
items:
- email compositing library with the message builder (which can be used 
by any application that wants to send mail without having the need for 
the composer GUI, e.g. by KOrganizer for sending invitations)
- mail dispatcher agent for doing the actual sending
- Plasma thingy for managing the global outbox. IMO, this is a must-have 
for interacting with the mail dispatcher agent.
- (optional) D-Bus service for sending mail (via the mail dispatcher 
agent) for applications that do the email compositing on their own

Extracting the composer GUI from KMail could be done in a later step 
once the above prerequisites have been completed.


> In general, looks good. I'm unsure about including POP3 or the mail
> dispatcher agent, I don't think there's enough time for it, I would
> rather see the composer done properly.

I agree that POP3 is out-of-scope, not only because of lack of time, but 
also because it doesn't really fit to the rest of the proposal.


> It would be nice if the GUI 
> component base could be shared with KNode, since there's no reason
> that KNode has its own composer GUI. With Mailody, we probably only
> want to share the builder.
>
> So I would propose to take out the POP3 and probably the mail
> dispatcher agent, and focus more on KNode and Mailody as optional
> goals. As you have the reader stuff as optional in there as well, we
> won't run out of things to work on.

I'd keep the reader out as well for the same reasons as the POP3 agent.


> Otherwise, nice proposal, I keep my fingers crossed for you being
> accepted.

Ditto.


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/20090325/91c4229e/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/