On Thu, 6 May 2010, Dan White wrote:
And what do you do if the server takes longer that you think it should to
respond to a query? Do you assume that it's a networking issue or a slow
server?
Crapware assumes that it is a network issue that somehow is utterly
irrecoverable in TCP, yet magically goes away if you tear down the TCP
connection and establish a new one.
Guess what happens when thousands of pieces of crapware are all doing the
same thing at the same time. It gets ever more entertaining as additional
crapware (with longer timeouts but not long enough) join in the
festivities. Typically, the original event that triggered the problem has
long since resolved itself.
It's very much like a minor traffic slowdown that escalates into a traffic
jam that escalates into a mass freeway collision. And no matter how many
times you attempt to educate people about maintaining a safe following
distance and safe lane changes, they still do the same bad things.
Treating an IMAP *session* like a stateless http request is doomed to
repeat history. RFC 2683 covers some of this ground.
Yup. The stateless religion was absolute dogma in CS classes starting in
the late 1970s/early 1980s. As a result, many of the young'uns simply
have no clue how to think otherwise.
Yet, over and over again, the same young'uns end up beating their heads
against a wall in an attempt to re-implement state. When they talk about
the problem they are trying to solve, they confuse it with "cache". When
a young'un talks about "keeping the cache synchronized", I listen
carefully. More times than not, s/he's trying to keep state but doesn't
know how to it.
The whole basis of the stateless dogma 30 years ago was the belief that it
is less inefficent to jump through hoops to attain state in a stateless
world than to maintain a stateful world if you didn't care about state.
I first became aware of it with PARC's Woodstock File System which was the
ideological predecessor of NFS. The WFS paper became the manifesto of the
stateless ideology; yet only a few read it and even fewer noticed that it
rather coyly defined out of the problem space all the cases in which
statelessness did less well.
Basically, statelessness requires accepting the following on faith:
. State is unimportant.
. State is expensive to acquire and maintain.
. If state is important, it can be easily and cheaply acquired on
top of a stateless infrastructure.
. If state can not be easily and cheaply acquired in a stateless
infrastructure, you can get the equivalent effect easily and
cheaply through synchronization.
. Synchronization is magically atomic, so you don't have to worry
about the fact that it is stateless.
. If synchronization is not atomic, and things change in the middle
of the synchronization, it is alright since you'll notice the
issue the next time you synchronize.
There is more to the faith of statelessness, but this ought to be enough
to see the overall picture.
The bottom line is that IMAP is a stateful, not a stateless, protocol; and
that "treating an IMAP session like a stateless HTTP request" is doomed to
failure.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
