> It implies nothing of the sort. A client's decision to cache any part of a > message for eternity is purely on the shoulders of the client. It has no > bearing on how the server should store the data.
While this is true, a client's ability to cache the message if it so chooses is promised by the IMAP protocol. > Again, think of a browser. I could set the caching such that the first time > I visit a web site, that web page is cached forever, but I claim that > wouldn't be very useful. 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. > > The only way for a server to invalidate the client's cache is to send an > > EXPUNGE for the relevant message and issue a new UID. > > With current clients, I absolutely agree. But, as I mentioned into another > reply, I think enabling updates for current clients is not necessary. What > is necessary is that they don't break. Newer clients will be able to make > use of an update capability. Perhaps I am misunderstanding. Are your proposing the ability to update a message without changing the UID, or not? If so, then how do you propose that existing clients not break? How do you update a message that an existing client has cached? If not, then I don't think there's any disagreement: essentially you're proposing some sort of optimized append (append-based-on ...). john ----- Original Message ----- From: "John Milan" <[EMAIL PROTECTED]> To: "Arnt Gulbrandsen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, March 19, 2003 7:32 AM Subject: RE: Why is a message immutable? > > > > In IMAP, a client is free to cache any part of a message for as long as it > > wants. That implies that once a server has sent e.g. a message's ENVELOPE > > to a client, that message can't be changed any more, or the client's cache > > would hold incorrect data. > > It implies nothing of the sort. A client's decision to cache any part of a > message for eternity is purely on the shoulders of the client. It has no > bearing on how the server should store the data. > > Again, think of a browser. I could set the caching such that the first time > I visit a web site, that web page is cached forever, but I claim that > wouldn't be very useful. > > > The only way for a server to invalidate the client's cache is to send an > > EXPUNGE for the relevant message and issue a new UID. > > With current clients, I absolutely agree. But, as I mentioned into another > reply, I think enabling updates for current clients is not necessary. What > is necessary is that they don't break. Newer clients will be able to make > use of an update capability. > > JM > >
