[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-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2005-05-27 14:32:00
Message-ID: 200505271632.03491 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 27 May 2005 03:25, Don Sanders wrote:
> On Thursday 26 May 2005 23:56, David Faure wrote:
> > This makes the MessageProperty forget that this message is
> > complete. If it's allowed to make copies of messages,
>
> You can't have two different messages (an original and a copy) with
> different serial numbers. A serial number relates to a unique message
> in a particular folder at a particular offset within the index.

Correct. But this means that a message in memory can never have a serial 
number. The serial number always refers to the message in the folder, 
i.e. on disk or on the IMAP server.

> > then deleting
> > a copy shouldn't make kmail forget about the properties associated
> > with its serial number - there can be other copies of the
> > KMMessage/KMMsgBase which needs them!
>
> If the copy is in a folder then it should have its own unique serial
> number. If the copy is not in any folder, then it exists only in
> memory and should not have a serial number.

Well, if a message is show in the main window and in the separate window 
then it's both times the same message. It's just two different 
representations of the message (cf. model-view). The serial number 
connects the views (and all actions which work on messages) with the 
message in the folder.

Of course, this leads to problems if a message which is shown in the 
separate reader window is deleted by the user. There are two ways KMail 
could react:
a) Automatically close the separate reader window which shows the 
deleted message.
b) Keep everything working as if the message wouldn't have been deleted.

ad a) I guess we all agree that this option sucks and thus is not the 
way to go.

ad b) The problem with this is that we will have to make all actions 
work on serial number _and_ on KMMessage objects. Obviously that does 
also suck. So currently the only solution I see is as follows:
- All actions work exclusively on serial numbers.
- Normally all message views reference the same serial number/physical 
message.
- If a message is deleted in one view while it's still referenced in 
another view (well, actually only if it's still referenced in a 
separate message window) then we have to put a temporary (complete?) 
copy of the message somewhere (in a local folder on disk? just in 
memory?) and assign it a new serial number. Or in fact we could simply 
keep the serial number.
An alternative to putting a temporary copy into some other folder would 
be to delay the deletion of the message until the message is no longer 
needed. Obviously this requires reference counting of the serial 
numbers.

> > Either we need to refcount the kmmessage copies (ouch), or we need
> > to forbid making copies (double ouch),
>
> You can't have (it's incorrect to have) two distinct messages with
> the same serial number, that breaks the uniqueness of serial numbers,
> and if that occurs indicates there is a logic error in the code.

Correct.

> > or we need to simply forget
> > about forgetting :) i.e. what about removing the forget(this) call
> > from the KMMsgBase destructor?
> >
> > Which problems can we get if we keep information about a deleted
> > message (associated with a now-unused serial number?). Other than
> > the minor memory consumption, I think this should be OK, right?
>
> Maybe you could get weird errors because some of the messageProperty
> stuff works on KMMsgBase pointers, this seems dangerous to me.

And it seems totally wrong to me.

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]