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

List:       kmail-devel
Subject:    Re: Serial number-related trouble, again
From:       Don Sanders <sanders () kde ! org>
Date:       2005-06-14 4:53:10
Message-ID: 200506141453.10619.sanders () kde ! org
[Download RAW message or body]

On Sunday 12 June 2005 07:14, Ingo Klöcker wrote:
> On Saturday 11 June 2005 16:32, Till Adam wrote:
> > On Friday 10 June 2005 06:50, Don Sanders wrote:
> > > 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 fully agree to this.

I concur. I also fully agree. Well put Till.

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

ACK^2.

But you know it may be easier said than done :)

IIRC the problem was lots of stuff was getting called in constructors 
beore the message had a serial number.

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

Yes that's near the top of my KMail todo. I'm not sure if I should use 
one folder for all accounts though or one temp folder per account. 
I'm favoring the later option.

> Apart from the fact that IMO we'll need different internal folder
> for the different purposes (because messages opened from files and
> deleted-but-still-referenced messages can simply be deleted on the
> next start while any messages which are found in the
> temporary-filter-folder should be moved to inbox or should be
> filtered again).

Ok. Yeah so different folders then :)

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]