On Thu, 2003-03-20 at 20:57, John Milan wrote: > And, as mentioned, clients that are "UPDATE aware" can flush their cache and > re-fetch at their discretion. But there are two issues: > > 1) UPDATE non-aware clients > 2) Multiple clients > > I claim issue 1 is actually a non-issue. Update non-aware clients are > allowed to continue on in blissful ignorance.
No, that won't work. Clients may have cached only parts of the message. Now what happens if you modify the message, but client has it partially cached and tries to fetch the rest of it? Trying to continue partial body[] fetch could give you completely corrupted message. > But remember all the carnage on the roads predicted when > the 55 mph speed limit was raised? (I just had I had to work that back in :) Bad analogy, you didn't have to buy a new car that went 55mph. New limits didn't cause _any_ problems for older cars. Your UPDATE proposal does so far. If what you want is permanent IMAP URLs, how about this: UPDATE <uid> command. Works just like APPEND, except doesn't permanently delete the old UID. When someone tries to access the old UID, server gives "* OK [UPDATE <olduid> <newuid>] Message was updated.". Perhaps even return the FETCH results for the new UID after that. Fully compatible with old clients and no horrible kludges needed to support it.
