(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.3.1 (using KDE 2.2.0 ) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk) OS: Linux (i686) release 2.4.6 OS/Compiler notes: DnD one or several mails to another mail. This adds an In-Reply-To header to the first mail pointing to that other mail. Maybe there should be a question "do you really want to put the selected mails into thread "blablalbal" ?" with an option to suppress that question. Remark from Ingo Klöcker: But adding an In-Reply-To header isn't such a good idea because the message would have to be copied at the end of the file corresponding to the folder (at least if the folder is in mbox format). It would be easier to add some kind of pointer to the index file. The disadvantage of this is that this information will be lost if the index file has to be rebuild for some reason. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 19 August 2001 20:57 wrohdewald@dplanet.ch wrote: <snip> > Remark from Ingo Klöcker: > > But adding an In-Reply-To header isn't such a good idea because the > message would have to be copied at the end of the file corresponding > to the folder (at least if the folder is in mbox format). It would be > easier to add some kind of pointer to the index file. The > disadvantage of this is that this information will be lost if the > index file has to be rebuild for some reason. <snip> Don is the index format flexible enough (or can it be made so) to act as a "changed header cache" for mbox? I'm thinking about both status updates (X-Stataus/Status) and things like the above ("X-KMail-*" headers...). If such a header is written to a message in mbox format then the change is cached in the corrsponding index file until the next compaction incorporates these changes into the mbox file. Thus we could tell people that once a folder is compacted it will maintain the status of the messages at that checkpoint even if the index files get corrupted. Marc - -- The road is still long. Thank you everybody. Thanks to all who make an effort on behalf of democracy in China. They have come. Goodbye. -- last EMail of Huang Qi webmaster of 6-4tianwang.com sentenced in China for posting Party-critical texts. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7gQQN3oWD+L2/6DgRAlxHAKCMcLifVBfafzNqe2vZ0SNyO/bcngCfbsOy 4NXvQLiVFPK2GHW57VPemj8= =J4XB -----END PGP SIGNATURE-----
On Monday 20 August 2001 14:35 Marc Mutz wrote: > On Sunday 19 August 2001 20:57 wrohdewald@dplanet.ch > wrote: <snip> > > > Remark from Ingo Klöcker: > > > > But adding an In-Reply-To header isn't such a good > > idea because the message would have to be copied at the > > end of the file corresponding to the folder (at least > > if the folder is in mbox format). It would be easier to > > add some kind of pointer to the index file. The > > disadvantage of this is that this information will be > > lost if the index file has to be rebuild for some > > reason. > > <snip> > > Don is the index format flexible enough (or can it be > made so) to act as a "changed header cache" for mbox? I'm > thinking about both status updates (X-Stataus/Status) and > things like the above ("X-KMail-*" headers...). Yes the index can hold optional fields now. But you have to be sensible and only write the value of the field if it is not equal to the default value. Otherwise space will be wasted ny the index file. Kurt's patch wasted some space in all index files that really was only needed for maildir folders but it was just a QString field that will take up a few bytes per entry so I didn't care. It would have been better to only write that index field if the QString was non-empty and use an empty string as the default value. As a further benefit new index fields can be added without having to update the index version number. Old versions of KMail can still read these newer index files they will just ignore the new fields. > If such a > header is written to a message in mbox format then the > change is cached in the corrsponding index file until the > next compaction incorporates these changes into the mbox > file. Thus we could tell people that once a folder is > compacted it will maintain the status of the messages at > that checkpoint even if the index files get corrupted. Okay you will need another (optional) header field in the index that marks a message as needing updating during compaction then. Now compaction is optimized so that raw bytes are operated on rather than KMMessages. So you will have to create a KMMessage only in the special case the message-needs-updating-during-compaction index field is set. Don.
*** This bug has been marked as a duplicate of 25594 ***