On Wed, 2003-01-29 at 18:59, Cyrus Daboo wrote: > |> I don't believe I'm forgetting anything... > |> Adding something to the protocol does not cause backward incompatibility. > | > | No, but neither does it fix the issue with non-supporting clients. > | Server is still broken with them. > > This begs the question - how many clients out there now know how to deal > with the problem of renames and keeping there caches in sync now?
I would think they notice the change in UIDVALIDITY and behave accordingly. Why should RENAME be any different? Keeping the old cache isn't that important to me, more important is that it doesn't keep it when it shouldn't. NEW-UIDVALIDITY would be just extra, the real solution is about updating the UIDVALIDITY values. > Given that, I think it > would be better to fix this problem properly - and IMHO that means global > UIDs. Note that global UIDs not works for the client that does the rename, > but also for other clients that have disconnected caches of the renamed > mailbox - NEW-UIDVALIDITY only solves the problem for the client doing the > rename, and that is not enough. Well, if you really want all the disconnected clients to be able to keep their cache.. I guess it would be possible to create GLOBAL-UIDVALIDITY which would guarantee that guidval+uid would uniquely identify the message within the user's all mails. Except how do you guarantee it's uniqueness? Think shared folders for example. It would really have to be global among all users, which could be pretty difficult to implement safely.
