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

[Szymon Tomasz Stefanek]

On Saturday 13 December 2008, Ingo Klöcker wrote:
> On Saturday 13 December 2008, Szymon Tomasz Stefanek wrote:
> > [...]
> > - 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.

Hm... I agree that this may be a matter of personal taste.

However I can cite a couple of arguments in favor of subfolders
(trying to speak generally now, even if I cite KMail examples)

- For instance, they are good for creating structured software.
By putting sources in a subdirectory you say "this is a component"
and you create a logical boundary which developers should cross
with some level of care. This helps a lot in modularization
and modularization is good(tm). Just look at what we have now:
it's _very_ hard to reuse any part of KMail as it is now because
it's not modularized at all.

Modularization doesn't necessairly imply separation of code
in libraries. Libraries are useful when code sharing is requested,
but also add some level of complexity to the (C)Makefiles,
to the user app code and to the library code itself. When
code sharing is not requested libraries are mostly useless
but still modularization is a desiderable feature.

The messagelistview folder is an evident example. 

The MessageListView namespace is *all* inside the messagelistview
folder. Nothing outside of that directory deals with the message
list display. That subdirectory offers an API which the code outside
uses. So MessageListView is a module, even if it isn't a standalone library. 

Furthermore the MessageListView namespace has two layers
and this is reflected in the directory hierarchy.

MessageListView::Core is a layer that is 99,9% independent from
the KMail code: you can turn it into a library in 4-5 hours of work. 
Anything outside MessageListView::Core is a "glue" layer which
is tied to the kmail internals (but still uses offers an API for
others to use it). If we make MessageListView::Core a library
then any app using it will need to write such a "glue" layer.

- You might be used to the kmail sources but *personally* I find
it very hard to find what I've been looking for.

In a flat list you basically need a linear search on the whole folder to find 
a concept that you don't exactly know the filename for.
Now that the km* prefix is only partially phased out it's becoming
a real pain... the alphabetical order is broken...

Instead with folders: want to work on on the message view ?
Go to the messagelistview directory :)
Inside you find few files with self-speaking names. Quite logical.

- I see that many KDE important subprojects gone the subfolders way
(just for instance, kcontrol, plasma, kdm, libkdeui, libkdecore...)
There must be a reason for this ;)

- As the project gets larger and larger it's very unlikely that you will
be going to work on more than a couple directories at a time...so not
a lot of directory jumps are needed.

> > - Develop a reference counted abstraction layer for the storage
> >   (and place it in subfolder "storage"):
> > [...]
> > 	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?

Well.. IMO this is the only possible "non destructive" approach.

All the other approaches will require working in a branch for months
or years or to write a parallel project from scratch that will be not usable
for a long time.

> I think this is a waste of developer resources. Furthermore, I think we
> need a much more radical approach.

Yes, this is the other way. My above reasoning is made on the assumption
that KMail is a workhorse and we want it to live :D
If this assumption fails then the whole "road to kmail/akonadi" plan doesn't
make much sense. This should be discussed, decided and made clear
to everyone at a certain point.

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

Isn't Mailody the project you're talking about ?

Well.. it doesn't use KMail parts, but this could change in the future...
I've been just talking about the KMail::MessageListView::Core namespace...

> I guess we should decide which way to go during the Osnabrück meeting in
> January.

Yep, that should be a point of discussion.


Szymon Tomasz Stefanek
_______________________________________________
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/