GNOME Bugzilla – Bug 222319
Replies should be linked to the original (and vice versa)
Last modified: 2005-05-19 08:14:06 UTC
Evo knows *if* you reply to a message and tags the message as such. It also can be configured to automatically save replies to messages. It would be nice if the two were actually linked such that once you reply to a message a button or link appears that you can click which will warp you to the reply you made (if you are saving them) and the reply should also have a link back to it's parent. This should work across folders (obviously) and should continue to work even if you refile mail (as long as you use evo to do it, anyway) and in VFolders.
ugh, this sounds like a royal PITA to implement (if it is even possible to do at all). :\
you should be able to add: X-Evolution-reply=msgid-of-reply and some other algorithm for multiple replies. doesn't sound that hard to me.
that's because you don't know the full issue. The problem is you have to keep track of more than just the Message-Ids. There is no way to get a message from just a Message-Id. You'd have to scan the entire folder - and that's assuming you know which folder it is in! But lets for arguments sake say that you also store the folder url with the Message-Id in that header. Okay, now you'd got all the information you need to find it, but you still have to search message by message through the folder. That's pretty slow. Okay, so lets use the message's UID for that folder (UIDs are not guarenteed to be unique accross multiple folders) in place of the Message-Id. Now we can directly request the message from the folder without searching. Yay! Problem solved? No. Btw, assuming that this did solve the problem, it's still too slow because: If the user is using mbox, we'd have to rewrite the entire mbox spool to change the ehaders of a single message because that is how badly mbox sucks. If the user is using IMAP, we'd have to download the message(s), add the header, and then re-upload. This can be slow depending on the size of the message and the bandwidth the user has. So... where was I? Oh right. Now we have to solve the issue of the user moving either of the messages around to different folders. Joy. So basically, everytime the user refiles either message, we have to change the header of the message not being moved which means rewriting that mbox again! How does Microsoft Outlook do it? It cheats by storing mail in a proprietary SQL-type database so that no matter what "folder" a message is visably in, it's all stored in the same place. Thus a simple query will find that message for you and refiling a message to a new folder isn't a real move - it's just a change to the message's "folder" attribute in the database.
so it is not hard given you can get a message from a message id (which would seem like a sensible api to have in camel). as for performance issues, what happens when you add the X-Evolution header to mails? anyway it doesn't matter as it's probably never going to happen. but it still is not the hardest thing in the world to do :/
the X-Evolution: header has a defined number of bytes for the value, so all we have to do is seek and rewrite that value because it won't change the size of the message. You can't do that with arbitrary URL strings (unless you can guarntee that all urls are <= a certain length and we could use spaces as padding or whatever) Your API suggestion means that we would have to keep a database of where each message was stored because doing camel_find_message_by_message_id (const char *message_id); without that database would mean that we would have to do: foreach CamelStore that the user has configured do foreach CamelFolder in current CamelStore do foreach message in current CamelFolder do if (message->message_id == message_id) return message; I hope you can see the inefficiency there ;-) However, another solution might be to store the folder url and uid in the folder summaries rather than in the message itself. This would avoid having to download IMAP messages and rewrite entire mbox files, but you'd end up with 2 problems that I can see: 1. If you have multiple Evolution clients running at different locations on the same IMAP server, they wouldn't be able to both be able to follow the replies etc (because they would each have their own folder summaries). 2. If the folder summaries need to be regenerated due to the user using mutt on his mailboxes locally, then the info will be lost. Maybe this will be acceptable to users though, I dunno. But rewriting entire mbox files would not be. Nor would having to search each message of each folder of each store that they had configured.
*** Bug 242196 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 200171 ***