Hello all,
First of all, I'm a newbie, so my deepest apologies for raising old
wrecks
BUT
I've been scratching my head over why the latest IMAP specification has been
changed such that ENVELOPE and BODYSTRUCTURE are now explicitly immutable
(RFC 2060 was mum on the issue).
I finally found the original thread from May of 1998.
http://www.washington.edu/imap/listarch/1998/msg00514.html
Which led to this summary that seems the simplest to understand:
This is exactly why I raised my initial objection, and after discussing
this with Mark, he and I agree that messages that are modified in any way
that would cause a modification of the ENVELOPE or BODYSTRUCTURE are
different messages, and thus the UID of the message MUST be changed.
This strikes me as a rather strange argument. Mark must have some very
impressive powers of persuasion because this is quite at odds with most
other implementations of unique identifiers and its data. Certainly anyone
familiar with databases would disagree that changing a piece of data
requires changing its key. But I have a feeling 'database' is a dirty word
here, so scratch that example.
Instead, let's look at other examples. The address of my house stays the
same regardless of whats in it. My bank account number stays the same
regardless of how little is in it. If I want a snapshot of what's in my
house, I take a picture. If I want to know what my bank balance was on new
years day, I can either save the data file on news years day or perform a
search for what it was on a particular date (aha, you might say, you
contradict yourself. you are actually searching many messages, each
containing a particular days bank balance. please read on).
Lets look at the most successful universal identification scheme in recent
memory: the URL. If I type in http://www.cnn.com I expect my web browser to
be able to locate that address. If the CNN website happens to be the same as
when I left it, great. If it happens to be updated from the last time I
viewed it, fine. If it changes tomorrow, no problem. I always see the
current content for the http://www.cnn.com identifier. Speed concerns are
handled by simple and well defined caching rules. And again, I can save a
particular day's page if I want to.
So what are some concerns? In the thread I cite above, one person raised
server performance concerns. Even if this is the case, I firmly believe in
our ability to come up with reasonable solutions-- especially with today's
horsepower.
Another issue raised was there is no way in IMAP to make a message change
(apart from flags). But this can be solved by creating a way in IMAP to make
a message change (and yes, I hope I have one :)
I can only think of two arguments at this point (though I'm sure there's
more, please contribute):
1) The philosophical 'What is a message?'
2) The very real possibility of breaking lots of running clients.
Let's address the second argument first. I claim IMAP is flexible enough,
and we are smart enough, that we can collectively come up with a solution
that won't break all clients. Call me an optimist.
So assuming argument 2 is an excercise left to the reader, we are left with
argument 1: 'What is a message?'. Good question. As you recall, earlier I
seemed to contradict my own argument that pointers and data are disjoint.
Back to the bank account example. In order for me to see what my bank
balance was on new years day, I would need to find the 'message'
corresponding to my account number, dated new years day and containing the
balance. So I would need a series of messages, right? Right.
But is this the same message that corresponds only to my account number? NO.
What we have are two sets of messages. Set 1 contains a message with a UID
consisting only of my bank account number (and since I have only one bank
account, it's a small set). Set 2 contains copies of that single message in
set 1, but created on a recurring epoch: the changing of a day (and since
time marches on, its more substantial). These two sets don't really have a
whole lot in common. There probably exists the ability to move from the
current bank account message in Set 1 to the new years day balance message
in Set 2, but its not required as a function of its UID. As for creating the
two sets, I could have been diligent and punctual and manually COPIED my
bank account balance message from one mailbox to another every midnight, but
thankfully it was done automatically.
But surely the messages in Set 2 are immutable, right? Obviously you've
never worked in a bank :) For example, what if I wanted to see my bank
account balance on Jan 1, 2000, which, because of the Y2K bug, accidently
had a value of $1 million for a short while? Would my account still show $1
million for Jan 1, 2000 if I search for that message today? Absolutely not!
Because someone caught the general error, updated the automatic COPY
routine, and then updated the faulty account data in the message of Jan 1,
2000.
