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

List:       kmail-devel
Subject:    Proposal for a new developer
From:       Bo Thorsen <bo () sonofthor ! dk>
Date:       2003-07-22 11:44:46
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
- - Makes it almost impossible to implement changing storage types
- - Makes the class bigger
- - Provides a tight coupling that is not necessary (why should KMReaderWin 
have access to maildir stuff?)
- - Should be less fragile than the current approach

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?

Bo.

- -- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/HSOumT99lwfUS5IRAkcvAKDTW9U/kz4zm5yVyb0T/av/bQDLuACgqV2e
258a7MTscbco67ZDv1If8l0=
=jRi8
-----END PGP SIGNATURE-----
_______________________________________________
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]