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

[Ingo Klöcker]

On Saturday 13 December 2008, Thomas McGuire wrote:
> 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.

Szymon's proposal and my proposal do not necessarily exclude each other. 
We do not need to rewrite everything (actually I hope we can keep a 
good deal of the code with only minor adaptions), but at least the 
folder view needs to be rewritten anyway based on Akonadi's collection 
model. The message list has already converted to model/view so 
hopefully there's not too much left to do.


> 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.

Exactly. That's why I favor a radical cut over a gradual transformation. 
Also I believe it will take more than one release cycle to port KMail 
to Akonadi and I don't think there's an easy way for supporting a 
gradual transformation as there is with Kevin's KResource bridges for 
KAddressBook and KOrganizer.


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/20081213/b3b77e85/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/