> How do you propose telling the client that it needs to update the cached
> value? Or is the client just supposed to guess that it might need to
> check?
I would make use of unrequested, untagged server responses carrying flag
information for a particular UID. The client could receive, at any time, the
following:
S: * 23 FETCH (FLAGS (\Unseen))
Nothing more. Certainly not the entire message or even its header. This
would be a signal to the client that, if it has message 23 in its cache, it
should remove it. The client could then determine if and when it wants to
fetch the 'new' data for UID 23. Perhaps when the user actively selects the
inbox the message resides in. Or perhaps on a timer, or perhaps when it gets
the unrequested message. It would be up to the client.
> The current IMAP specification says that you change the UID, send an
> expunge for the old message and an EXISTS for the new one. So
> effectively you've created a new message.
Hmmm... you may have effectively created a new message, but you've
definitely duplicated data and took another hit on the cache. This isn't
something you'd want to do for updates coming in at high frequency, any more
than you'd want many annotations.
Federal law used to say cars on the highway couldn't go faster than 55.
Things can change.
> the bodystructure on a message (and servers CAN do that, it's perfectly
> legal), you need to create a new message from the clients point of view.
> It doesn't need to be a new message on the server, the client needs to
> THINK that it's a new message.
This strikes me as a bit odd. In a sense you are then keeping multiple views
on the server indexed by clients. It seems like you'd have a hard time
scaling this, since there are alot of potential users in the world. It seems
like this is a problem created from a solution created for the problem of
requiring new IDs for updates.
> In fact, the Exchange server can and will do just that. If a client
> modifies a message on the Exchange server (you can do that for messages
> that you authored if they've not yet been sent), when the client saves
> their changes on the message, the server assigns a new UID to the
> message and sends an expunge for the old message.
OK, then other then the IMAP specification saying you needed a new UID, what
technical reason is there for creating a new UID?
JM
