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

[Ingo Klöcker]

On Sunday 14 December 2008, Szymon Tomasz Stefanek wrote:
> 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.

We should probably still go for libraries even if code sharing is not 
yet an issue. When the desire for code sharing arises (e.g. with KNode 
or Mailody) there will be nothing left to do. Also libraries ensure 
that we do not inadvertently introduce cross-dependencies because the 
linker will complain about this.


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

That's a pain I share with you.


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

Yeah, well, I guess I should simply start using KDevelop so that I don't 
have to think about artificial hierarchies created on the level of the 
file system.


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

This I doubt. It might lack some of of KMail1's features for a long 
time, but it should be usable without a short 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

Yes, KMail1 is a workhorse. Therefore I want to avoid larger 
reconstruction work on its core. Since the code is very fragile any 
restructuring will have to be done with extreme care and consequently 
it will cost a lot of developer resources, resources we do not really 
have.


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

This came also to my mind when I wrote my proposal. I don't think 
Mailody is this project because Tom has a completely different vision 
for Mailody as far as I understood. But we could probably borrow some 
code/ideas from Mailody.


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

Okay. See you there.


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/20081214/ec83828e/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/