[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Proposal for a new developer
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-23 2:27:57
[Download RAW message or body]

On Tuesday 22 July 2003 21:44, Bo Thorsen wrote:
> Hi all,
>
> I have been increasingly annoyed by the KMFolder inheritance tree,
> but as usual have not been able to come up with any spare time to
> do something about it. I'm sending it to the list now, so people
> can chew on it until Nové Hrady.
>
> The problem I'm adressing is that I think it's wrong that KMFolder
> is both about folder access and storage. There are several reasons
> why this seems wrong:
>
> - Conceptually these are two different things

I think I understand.

> - Makes it almost impossible to implement changing storage types

Well you have to delete the old KMFolder object and create a new one. 
It would be nice if the storage type could be changed without 
deleting the folder object.

> - Makes the class bigger
> - Provides a tight coupling that is not necessary (why should
> KMReaderWin have access to maildir stuff?)

KMReaderWin does? Yuck, where does it do that?

> - Should be less fragile than the current approach

Some concrete examples would be nice.

We should be careful of the I don't understand the code so I want to 
rewrite it syndrome:
http://www.joelonsoftware.com/articles/fog0000000069.html

> What I'm proposing is to split it to two classes: Folder and
> Storage (getting rid of the KM prefix). Folder is not inherited by
> anything, but has a pointer to the internal storage. Storage is an
> abstract class, inherited by StorageMaildir, StorageMBox,
> StorageImap, StorageSearch...
>
> This transition can be done without any user being able to see it,
> and will IMHO pay off by cleaning up the code.
>
> The biggest benefit for users is that it will be possible for us to
> provide actions to change storage of a folder from maildir to mbox,
> or IMAP to disconnected IMAP and back. However, this gain is not
> possible if we allow other classes to get a pointer to the Storage
> object, so the implementation of Folder must not make this
> possible.
>
> This should be a nice project for any lurkers on this list who have
> looked at the occasionally hairy code of the backend of KMail. It
> is mostly about code reorganization, so you don't need intimate
> knowledge of the data structures. OTOH, you will gradually get this
> knowledge of all the classes involved in this.
>
> Assuming there will be no objections from other KMail developers
> (and that would surprise me :) and that there actually are persons
> on this list who want to start coding, here's an idea of an
> implementation roadmap:
>
> 1) Implement the Storage and StorageX classes
> 2) Make the KMfolderX classes use StorageX by just forwarding the
> calls (for example make KMFolderMaildir use StorageMaildir)
> 3) Implement the Folder class
> 4) Make KMail use the Folder class instead of KMFolder. This will
> involve *a lot* of classes - reader, composer, configuration... and
> is likely the step where a KMail coding newbie will need most help
>
> Comments or flames?

Why not simple rename KMFolder to KMStorage, and create a new KMFolder 
class that forwards calls to KMStorage and has logic to support 
changing the KMStorage object used?

Don.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]