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

[Ingo Klöcker]

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.


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

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.

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.


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/ba936c0e/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/