On Oct 26, 2013, at 7:11 PM, Ken Hornstein <[email protected]> wrote: >> Beyond that, email messages are generally large (compared to calendar >> entries, anyway) collections of text. Changes to messages mostly involve >> small deltas to metadata. > > Note that messages in IMAP are immutable; we don't have to worry about > changes to a message.
And thanks for quoting that previous text. I got a bit aggressive with the delete key and lost the message I was going to reply to :-P My comment about the incremental metadata changes being a small part of the equation was something I did not explain clearly. What I was getting at – and should have spelled out to being with – is that the major operation in the context of IMAP is the operation of moving a message from one folder to another. This is a full-on COPY+DELETE operation; you are instantiating an entirely new message, then destroying the original. Under the hood, this is considerably more than just fiddling with the meta-data. There is no equivalent to UNIX's link(2) that MH can use to shortcut the process. I.e., you cannot reuse things like inode numbers, stat(2) data, or most anything else, other than the immutability property of the message itself. And because IMAP messages are immutable, anno(1) fails miserably in the presence of an IMAP message store. Yes, there are some IMAP extensions that can help here, but any solution we implement would have to work with a server that implements only the base 3501 specification. --lyndon _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
