I'll take the last first :)
> > 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?
Because that's the mechanism that the IMAP server defined for indicating
to clients that a message has been modified.
You're right. When IMAP was designed back in the early 90's, a
different mechanism could have been designed along the lines of what
you're proposing (marking a message as being unseen when it's been
modified), but I'm pretty certain that just marking a message as being
unseen after its existance isn't sufficient (UIDValidity plays into this
as well).
> 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.
Now the rest: Ok, so you're saying that it's better to do:
S: * 23 FETCH (FLAGS (\Unseen))
Then (assuming 23 messages in the mailbox and the last one's the one
that's modified):
S: * 23 EXPUNGE
S: * EXISTS 23
?
I fail to see any real difference between the two approaches (although
I'm pretty sure that your use of the \Unseen flag is likely to have
significant issues in a multi-accessed mailbox case - the \Unseen flag
is defined as being seen by only one client, so if two clients have the
same mailbox opened simultaneously, this doesn't work. The *23
EXPUNGE/* EXISTS 23 paradigm doesn't have this problem.
> > 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.
That's happens with your proposal as well - you're just replacing one
mechanism of notifying the client to update the cache with another.
>
> Federal law used to say cars on the highway couldn't go
> faster than 55.
> Things can change.
Yes, but... Imagine a somewhat different scenario that's more relevant
to computers.
Imagine a hypothetical system service called "Open Handle" that's
implemented on the x86 interrupt 21h. Further imagine that the
documentation for this API says:
Call
AH = 3DH
AL
Access code (see text)
DS:DX
Pointer to pathname
Return
Carry set:
AX
1 = Invalid function code
2 = File not found
3 = Path not found
4 = Too many open files
5 = Access denied
12 = Invalid access
Carry not set:
No error
Remember, this is just a hypothetical, nobody in their right mind would
ever write such an API definition.
Now imagine that they decided that it was necessary to add a couple of
new error codes to deal with new scenarios (for example if they wanted
to add file sharing semantics to the system they wanted to add a
distinguished error code for "the file's in use by another process" to
the API assigning a new error code of 32 for that case(remember, this is
just a hypothetical, it would NEVER happen in real life).
But when they added the new value returned in AX, they discovered that
lo and behold - people had written applications that assumed that the
ONLY legal values in AX would be 1,2,3,4,5, and 12! And further, they
discovered that the people had used the error codes as indexes into an
array with 12 entries in it. And the new error code of 32 caused them
to go beyond the end of that table because they knew that the only
possible return codes were 1,2,3,4,5 and 12. And the apps crashed
horribly.
What would the system service developers do in such a hypothetical
scenario? Well, they'd probably add a table to the system that mapped
the new error codes to the old error codes, and add a new system service
to get the real return code.
If you have access to the NT source code (and I know that there are non
MS people on the list that do have access to it), you can look at the
file dostab.asm in the NTVDM tree if you want to see an example of such
a hypothetical table. The table in question was written in 1982, and
it's STILL a part of NT.
This got WAY more long winded than I expected. My point here is that
you can't just change the rules of a protocol on the fly after it's been
deployed, just like you can't change the rules for DOS applications
after the operating system has shipped. It's too late, the cow's out of
the barn and the barn's long since burned down.
Similarly, you can't change the semantics of the \Recent flag, because
you'd break every existing client AND server implementation out there.
There's a mechanism defined in IMAP for indicating non-metadata changes
to a message, it's "* <n> EXPUNGE/* <m> EXISTS".
If you want something about the message to change that's lightweight,
then you need to change the message metadata, NOT the contents of the
message.
Larry Osterman
