OK, I'd like to try and summarize the excellent points raised, so I started
a new thread.
>From the discussions, I believe I can state:
1) New UIDs are the mechanism that tells an IMAP client that new data is
available.
2) Without new UIDs, a client will not know that new data is available.
I believe, for the sake of backwards compatibility, *any* proposal to extend
IMAP cannot require a change to the above statements. I also believe a
mutable message doesn't conflict with the above statements (more detailed
explanation below).
Also from the discussions, two very reasonable alternatives were presented:
1) A COPY/APPEND and EXPUNGE is equivalent to UPDATE
2) An inbox could be the 'address' and clients read what happens to be
there at any given time
I disagree with alternative 1. This can best be shown by examining the
effects with regard to RFC 2192: IMAP URL Scheme. If I have a page on my
site, like http://www.foo.com/a/b/c/updateme.html, I can update the contents
of this 'message' (bear with me) and subsequent viewers of this URL will see
the updated contents. However, if in order to update updateme.html, I have
to remove updateme.html and create a new file with a higher id value
(updateme2.html), not only will noone be able to see the new content, but
now anyone who had bookmarks or references to updateme.html now has an href
pointing to a non-existent id. What's worse, they have no indication what
the new content is. I suppose you could have a chain of forwards until you
arrive at the most recent id, but that just increases the potential for
faliure-- one broken link the in chain ruins things.
However, alternative 2 would work. Excellent idea. The only problem I see
isn't technical but more usable, as in user interface. As a convention, it
seems to me mailboxes equate to folders as far as representation to the
user. And while I could create a large hierarchy representative of the data
I'm interested in, I'm not sure how comprehensible a giant tree would be .
This is not to say a folder listing 1 million files is somehow more
comprehensible, but the point of a hierarchy is to provide enough data to
the user so they can decide which path to pursue, *and*, perhaps more
importantly, which paths (and volume of data) to ignore. But maybe there's a
way around this-- or it's really not a problem. In any case, I do agree
alternative 2 could work. I'd like to explore it more.
But I promised a more detailed explanation back above. Here we go.
Since an update proposal could affect the behavior of UIDs with regard to
the current update mechanism, we must make sure updates do not change UIDs.
It's also a bad idea, as Mark correctly points out, to have ambiguity with
respect to the \Seen flag. People handle double entendre's much more easily
than systems. So ideally the indicator we use to let clients know new data
is available is a value that can only be set by the server.
Lucklily, because Mark is an excellent architect, IMAP has one:
INTERNALDATE. The server can update this value upon the successful update of
a message. I would also retract my proposal of signaling the \Seen flag to
~\Seen. In addition to the ambiguity mentioned above, ~\Seen also implies
the client and server are out of synch, but a successful update means that
the client and server would be in synch for that message, so the flag
wouldn't make sense.
So, if any clients are online, they would receive the following unrequested
server response:
S: * 23 FETCH (INTERNALDATE "13-Mar-2003 00:20:15 +0000")
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. If anything, it seems like an
opportunity to promote an upgrade cycle of IMAP clients in order to take
advantage of new features. This seems like a normal evolution of software.
Issue 2 is more interesting. There are at least two solutions. Solution 1 is
what Mark and Larry mentioned, and in fact what Exchange actually does:
maintain information per client. I was hoping Larry would add "And it turned
out to be extremely easy and massively scalable", but he didn't and its
probably not. Solution 2 would be to throw this into the UPDATE non-aware
client bin. That is, client #2 not seeing the updated data is expected
behavior of an UPDATE non-client.
So then the question becomes what would an UPDATE aware client #2 do to
learn it has updated data? This needs some thought, but what immediately
pops into mind is an UPDATE aware client performing a SEARCH upon selecting
an inbox. Since SEARCH only supports ON for INTERNALDATE evaluation, we
would need to add something like AFTER. Furthermore, I would add
INTERNALDATE as a valid response to a STATUS command.
These changes to SEARCH and STATUS would work since they are additions.
Furthermore, since they must be issued from the client, UPDATE non-aware
clients simply wouldn't issue them. Best of all, this is a proven method, as
demonstrated by html browsers, which use a simliar method to get header
attributes and examine whether or not changes have occurred.
Lastly, I'd like to comment on a few of the thoughtful opinions I read.
1) I think Draft is an excellent example of a message type that would
benefit from an UPDATE command. Wish I had thought of that.
2) "Adding any capability to IMAP to allow messages to be changed in any
piecemeal fashion would, in my opinion, make a nightmare of the protocol."
Actually, I was proposing this, but I agree this is biting off way to much
for a first cut. So I agree replacing the entire message is the way to go.
3) "Why not imagine a new protocol?" Because, truly, the world does not need
yet another protocol that overlaps with 98% of one or more existing
protocols. And because its OK for protocols to evolve, just like the
software written for them can evolve.
4) Larry's great "hypothetical" example of how easily things can break.
Definitely scary. 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 :)
I think there will always be examples of best and worst cases. But believe
me, your point is well taken, and as I've mentioned before, this is exactly
the kind of history people need to learn from lest they be doomed to repeat
it. My sincere hope is UPDATE will *only* be an extension that current
clients can blissfully ignore.
5) "I remain bewildered as to what benefit this is supposed to accomplish.
I've read the messages both to the group and in private email, and still
am no closer to understanding the point of this proposal. All I can see
is the danger of mass havoc that it would wreak."
Always save the toughest for last. I think the number one reason is to bring
the addressing model more in line with expectations built as a result of the
world wide web: which is an address can point to mutable data. This basic
tenet one reason they entire linking structure of the web: people expect
there will be *something* at the end of that link, as as a result include
these links in their own offerings. Furthermore, I firmly believe IMAP is a
very well positioned protocol to handle asynchronous bidirectional data
because it fully describes an extended session. If we begin broadening our
viewpoints of what a message is, or can be, then I think IMAP has the
potential as a necessary node in time-sensitive data. I've used stock
quotes, but that's the just a common used example. It's really just the tip
of the iceberg. You could imagine workflow systems, collaborative efforts,
instant message communications and more (and yeah, if you go to the
teamdirection website, you'll see *exactly* where I'm coming from).
So I sincerely hope the proposal isn't dismissed out of hand because it came
from some crackpot. I know UPDATEs have been discussed before, but a) I
didn't seem to be a very extensive discussion and b) Decisions don't have to
stand for eternity. What might not have been a good idea yesterday might be
a good idea today.
Please allow me to thank you all very much for the time and thought you've
given me,
John Milan
PS: An example of what the actual UPDATE command might be:
C: A600 UPDATE 1 (BODY[] {220}
C: From: "John Milan" <[EMAIL PROTECTED]>
C: To: "Anyone" <[EMAIL PROTECTED]>,
C: Subject: Proposal for IMAP extension
C: Date: Thu, 20 Mar 2003 10:43:06 -0800
C: Message-ID: <[EMAIL PROTECTED]>
C:
C: Hello IMAP
C: )
S: * 1 UPDATE (INTERNALDATE "20-Mar-2003 18:45:15 +0000")
S: A600 OK UPDATE completed
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
