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

List:       kmail-devel
Subject:    Re: Serial number-related trouble, again
From:       Till Adam <adam () kde ! org>
Date:       2005-06-11 14:32:06
Message-ID: 200506111632.07167.adam () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 10 June 2005 06:50, Don Sanders wrote:
> On Thursday 09 June 2005 23:35, David Faure wrote:
> > On Thursday 09 June 2005 07:49, Don Sanders wrote:
> > > I didn't want to bloat KMMsgBase with
> > > extra member variables, so the solution I found was to use
> > > KMMsgBase objects.
> >
> > This still makes no sense to me. You can use bitfields to add more
> > bools to KMMsgBase without any trouble.
>
> The advantage is that not even a bitfield is required. I only have to
> pay to store the information if it's required. A bit like the design
> philosophy of C++ (you only pay for what you use).
>
> Perhaps IIRC it's also an example of the flyweight design pattern.
>
> Basically we want to keep the KMMsgBase objects as small as possible
> as there's lots of them. (Ideally it would be best eliminate
> KMMsgBase entirely and just lazy look in the index and folder files
> but this wasn't easily doable in Qt3 and earlier, due to the design
> of the view classes like QListView. Maybe it can be done with Qt4)

To me the MessageProperty concept makes sense for transient properties, such 
as the filter target folder, filter manager or filter state, which are rarely 
needed during the lifetime of the object. It does not make much sense for the 
basic state of a KMMsgBase object, especially if it's just three bits 
(complete, readyToShow, transferInProgress). I would personally prefer to 
have the serial number, the primary key we use to identify the mail inside 
all of KMail (and even outside of it), reliably available from any pointer to 
a message representation (KMMsgBase or KMMessage) also. It never makes sense 
to "forget" a serialnumber, whether the message is complete or not, etc.

I therefor (David, note the lack of a trailing e, there ;) volunteer to revert 
the above mentioned properties to KMMsgBase members. 

As far as operating on serial numbers, and serial numbers only, whenever 
possible, that is necessitated by the fact that KMMsgBase and KMMessage 
pointers can become invalid at any time (unGetMsg/getMsg), so I see no way 
around that. The reader window needs to copy whatever it needs and hold only 
a reference to the message via its serial number. The special case of 
displaying a KMReaderMainWin with a message from disk or from a message 
digest needs to be either special cased, or worked around by putting the 
messages in the same "internal" folder that is used for temporary storage of 
deleted-but-still-referenced messages. That folder could incidently also be 
used for storing a message that is currently being filtered, but not yet in a 
folder (such as during incoming pop filtering) which would allow us to 
cleanly abort such a filtering process and push the mail into the Inbox, if 
something goes wrong. Don and I have discussed this possibility before, I 
think.

Till

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]