[Kde-pim] The road to KMail/Akonadi (was: multiple selection and hitting assert in KMMainWidget::slotMsgPopup)

[Thomas McGuire]

Hi,

On Saturday 13 December 2008 17:43:27 Ingo Klöcker wrote:
> On Saturday 13 December 2008, Szymon Tomasz Stefanek wrote:
> > On Saturday 13 December 2008, Thomas McGuire wrote:
> > > Typical KMail crash. The msg was deleted via unGet() behind our
> > > back and became invalid. Fixed in r896262.
> >
> > After 4.2 I strongly suggest planning an attack to the KMFolder &
> > KMMessage part of KMail. This is also a step in the KMail breakdown
> > plan for the akonadi port.
> >
> > We must assume that we have not enough work power for doing all this
> > in a short period of time so we should plan carefully a sequence of
> > small, compatible moves that can be done directly on trunk (and that
> > would help a lot keeping the branches synchronized) or in small
> > temporary branches.
> >
> > Some sketch ideas (please comment, expand, flame on...):
> >
> > - move the whole storage part into a source subfolder: KMFolder,
> >   KMMessage and anything that is more low level. This can be done
> >   in a rather painless trunk move.
> >   A good idea would be to move it even one level deeper.
> >   Say subfolder "storage/core".
>
> Please no subfolders. It's a PITA to navigate between different
> subfolders. Also I don't see the point in different folders unless you
> want to create a separate library.

Currently, KMail uses 3 pages when being displayed in WebSVN. I think 
subfolders help with separation of code, but maybe we should indeed do that as 
internal libraries.
If you use KDevelop, use quick open, which doesn't care about subfolders. But 
then, "compile file" is broken with subfolders there.

> > - Develop a reference counted abstraction layer for the storage
> >   (and place it in subfolder "storage"):
> >
> > 	- Wrap KMFolder in a shared reference counted KMail::Folder class.
> >
> > 	- Wrap KMMessage and KMMsgBase (both!) in a KMail::Message object.
> > 	  The Message object should be shared, reference counted and
> > 	  keep a reference to the folder, in some way.
> > 	  This will be probably a tricky part since complex (and sometimes
> > 	  weird) things happen in the current source at this level. Support
> > 	  from experienced KMail developers will be probably needed.
> >
> > 	This step can be possibly done without touching much stuff
> > 	in the existing source: it would be just a new layer wrapping some
> > classes.
>
> Is this really necessary? Won't we throw this stuff away as soon as we
> switch to Akonadi? If yes, then why do it in the first place?
>
> > - Move all the outside components to use the layer above instead of
> >   the original storage classes. This will be probably a large work
> >   to be splitted in small chunks for every subcomponent that needs
> >   to be ported.
> >
> > - When everything of the above is done (and it will take its time)
> >   think about attaching the akonadi storage layer in place of (or
> >   in parallel to?) the KMFolder / KMMessage machinery...
> >   (subfolder "storage/akonadi")
>
> I think this is a waste of developer resources. Furthermore, I think we
> need a much more radical approach.
>
> A lot of the functionality currently built into KMail will be outsourced
> to Akonadi resources (mbox, maildir, POP3, IMAP) and Akonadi agents
> (e.g. filtering, expiry, threading(?), sending). The composer should
> become a standalone application talking directly with Akonadi and the
> sending agent. The reader should become a KPart and/or a standalone
> application talking directly with Akonadi. This leaves us with a folder
> view, a message list and a "bit" of glue code that needs to be ported
> to Akonadi.

You make this sound easy :) I doubt it'll be easy or even possible at all to 
make the composer or the reader stand-alone, they depend on such much of the 
rest of KMail. But we can and should try, of course.

> With this in mind I propose to start a whole new extragear project
> KMail2 consisting of all of the above parts and re-using many of the
> concepts and as much of the code from KMail1 as possible. The
> development of this project will be completely based on Akonadi and
> KMime and it will take as long as it takes. To free as much developer
> resources as necessary development of KMail1 will be halted, i.e.
> KMail1 will enter permanent maintenance mode.

+1. We can't maintain two KMails in parallel, so KMail1 definitely needs to go 
into maintenance mode.

> The advantages of this approach are:
> - KMail1 will always be as usable and as stable as it is now (resp. more
> stable since we will still fix the most serious bugs).
> - We can fully concentrate on Akonadi without having to jump through
> several loops just to re-use/refactor the current code and keep it
> stable.
> - We have all the time of the world.
> - We will not be bound to freezes of KDE, so that we can run full-steam
> all the time.
> - We don't need to have all of KMail1's more esoteric features in the
> first release.
>
> I guess we should decide which way to go during the Osnabrück meeting in
> January.

I have to say I'm torn between the two approaches.
On the one hand, the current KMail codebase has lots of man years in it, with 
subtle bug fixes and features. Rewriting the thing will re-introduce bugs and 
features will be lost. Just look at KDE 4.0 Desktop or Amarok 2.0 how well 
that went. As Szymon pointed out, there are not enough people for such a 
rewrite. Doing it in extragear or wherever might help, but I'm still 
sceptical.
OTOH, the current KMail codebase is hardly fixable, the storage layer is a 
complete mess. Unfortunately, almost everything in KMail depends on that 
storage layer, so fixing or porting this in small tasks is very hard. And this 
way, a lot of ugly hacks and historical bad code would stay in.

So yes, let's discuss this in Osnabrück (Szymon: ping, will you be there?).

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20081213/3296106e/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/