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

List:       kmail-devel
Subject:    Re: Serial number-related trouble, again
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2005-06-11 21:14:00
Message-ID: 200506112314.05906 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

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

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

Regards,
Ingo

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