> The web browser analogy does not hold, mainly because HTTP either makes no > promises about the client's ability to cache the data, or it makes very > specific promises via certain headers. On the other hand, IMAP makes very > strong promises about the client's ability to cache the data.
I understand that one of the convenants of IMAP is a very strong promise to a clients abiilty to cache. I understand that this promises exists. What I don't understand is why. Of course, even a very strong promise is not absolute. I certainly know a few very strong promises that have been broken :) What I'm getting at is there are plenty of examples why client cache management isn't a technical issue. As a result, I fail to understand the value of this covenant. Is it because clients would have a very hard time? Or it would destroy what it means to be a message? The argument seems more philosphical than technical, and opinions don't change as easily as software. > Perhaps I am misunderstanding. Are your proposing the ability to update a > message without changing the UID? Yes I am. > If so, then how do you propose > that existing clients not break? How do you update a message that an > existing client has cached? I think it can be done via a command extension coupled with the use of the existing \Unseen flag. I believe clients, because of their caches, ignore UIDs that have been already cached, even if that UID has the \Unseen flag. I may be mistaken, but that's my claim at the moment. Newer clients could utilize the \Unseen flag as a cue to purge the cached data corresponding to that UID and FETCH it again. That's the theory. JM
