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

List:       kmail-devel
Subject:    Re: [PATCH] KMMsgDict refactoring
From:       Don Sanders <sanders () kde ! org>
Date:       2005-06-23 7:56:03
Message-ID: 200506231756.03525.sanders () kde ! org
[Download RAW message or body]

On Thursday 23 June 2005 02:20, Till Adam wrote:
> In an attempt to clarify how serial number handling is done in
> KMail, I started to read KMMsgDict, KMMsgList, KMFolderIndex and
> friends and decided to make that area of the code more self
> contained and consistent before proceeding with more serial number
> related changes. The attached patch does the following:
>
> o make the global message dict a real static singleton instead of
> managing it from the kernel. Provide a public access to a const
> reference to it, which all areas of KMail can use to look up in
> which folder a certain serial number (and therefor message) can be
> found
>
> o remove all knowledge of the dict from the kernel, the folder
> managers and KMFolder, and make FolderStorage instances register
> and deregister with/from the dict, which means filling in their
> respective set of sernums (persisted per folder storage, out of
> band, in the .folder.index.ids files) on creation and removing and
> writing them out on deletion
>
> o make FolderStorage, KMFolderIndex and KMMsgList friends of
> KMMsgDict and provide a protected mutableInstance() which allows
> those classes to write to the dict. This is a first step, KMMsgList
> should not need access, it's an implementation detail of
> KMFolderIndex, and I'm not sure which parts of the sernum (cache)
> handling should go into FolderStorage and which into its subclass
> KMFolderIndex. Any input on this is appreciated.
>
> o make KMMsgDict deal with FolderStorage instances exclusively, it
> now knows nothing of KMFolder, or anything above FolderStorage
>
> o port all users to the new KMMsgDict handling
>
> o make sure that serial number handling is done by nothing but
> FolderStorage derived classes. When adding a message they create a
> sernum, if the message added already has one, they update the
> message dict accordingly, same for removal of a message from a
> folder
>
> This only a first step towards a brighter future, currently there
> is still the in-memory serial number cache, which means that
> KMMessage::setMsgSerNum still has no effect on the message dict, it
> merely updates the in-memory serial number of the KMMessage
> instance. We need to discuss if want to keep this, or move towards
> a temporary folder for "floating" message copies, such they can
> have a serial number of their own. This patch should make sure,
> though, that at least code expecting setMsgSerNum to do otherwise
> (namely uses in KMFolderImap) now works since FolderStorage::addMsg
> does the right thing with messages which are added and already have
> a serial number.
>
> The whole idea of this is to clarify what does what, down there,
> and decouple the different layers of KMail a bit more, in the
> spirit of shining a bright light into some of our darker corners as
> part of the preparation for the spring cleaning that will hopefully
> be KDE 4. If you guys agree that this is a good direction to move
> in, then I'll continue trying to dis-entangle those classes (and
> rename some of them), bit by bit. I would like to get this part in
> first, though, and let is settle for a while, before proceeding
> with the next stage.
>
> Note to Marc: Once it is clearer which class(es) should actually be
> the ones responsible for manipulating the message dict, and what
> the interface for that is, we should probably get rid of the
> mutableInstance and friends thingie and move towards passing a
> MessageDict::instance().fillFromFolder( folder )
> { folder->fillDict( this ); } type interface, as you suggested.
>
> Thanks for reading this far. :)
>
> Till

I'm ambivalent if not slightly concerned about using a 'real static 
singleton' for the message dict. I decided to use one for 
KMBroadcastStatus (sp?) but ended up feeling like I hadn't gained 
anything. (Well maybe it made it easier to factor into a library).

I would suggest being especially carefully about the order in which 
objects are constructed and destructed, I have some vague memories 
about feeling pain due to the sensitivity of the order of 
construction of the message dict and the folder manager. (But if you 
end up making things more robust then great)

I'm definitely pro decoupling, but are a bit sad to see more friends 
being used, they're a bit icky.

No objections though, just comments.

Don Sanders.
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]