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

[Volker Krause]

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.

+1

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

I agree

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

Note that we are not talking about rewriting all those components but 
extracting them from KMail reusing most of the code. This worked nicely with 
the mailtransport library which was initially based nearly exclusively on 
KMail code and has seen some cleanup and refactoring since then. Isolated 
from KMail that was much easier to do.

Also, some of these components (reader, composer) could be integrated into 
KMail1 even if based on KMime with just minor overhead (one reparsing by 
mimelib, probably acceptable). I wouldn't try that with anything in the 
storage layer though, but it would allow for some kind of hybrid approach.

Working on backend agents for Akonadi would be also possible without starting 
a KMail2 already, they can be tested and used with eg. Mailody.

Regarding the folder and message view, I would like to move that one layer up 
anyway,  into Akonadi and the mail specific Akonadi lib respectively. They 
are useful beyond KMail and at least in case of the folder view even beyond 
mail.

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

With the component approach outlined above we can delay the creation of KMail2 
for some time I guess, while working on components that are immediately 
useful for either KMail1 or Mailody users. The actual KMail2 code is probably 
not very big anyway, just a bit of glue code between all the components and 
some KMail specific actions.

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

Definitely.

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/20081214/23de31a8/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/