I found this gem on imap-uw (via @hakmem) today.

The authors of Outlook and Thunderbird are victims
of a computer science course mindset which, starting in the 1980s, taught
their pupils that all protocols are (or should be) stateless. Thus, they
believe that IMAP is like HTTP; that when a server fails to respond
immediately, that means that the correct remedial action is to disconnect
and try again, or just disconnect and assume that everything happened
anyway.

I’ve heard many of the arguments for “stateless” protocols before, mostly before the current crop of advocates even entered the computing field (but more about them later). Too often, though, “stateless” just means that the state is harder to find. Usually it’s still there in the form of server-side session objects, client-side form fields, cookies, transaction IDs, or other devices. Sometimes it’s even more insidious, hidden in a configuration of the underlying data that implicitly limits what requests can still succeed. I’ve written about the evils of such implicit state before. When stateless-protocol dogma forces you to throw away context and then recover it later so that you can validate a new incoming request, the result is at best inefficient and quite often unreliable. Separating context from connection might be a good idea for various reasons, but it doesn’t really make the need for state go away. The only way there can truly be no state is if there are no rules whatsoever for when any data might be overwritten by any requester, and that’s just not a useful paradigm in the vast majority of cases.

This is related to why I dislike the currently fashionable REST dogma. REpresentational State Transfer is inherently a shared-state programming model. I’ve often said that sharing state without thinking about consistency is insane, and I’d say the same about sharing state without thinking about concurrency issues (e.g. races and deadlock) as well. It’s fine if you decide that you don’t need consistency or locking, so long as it’s a deliberate and considered choice which the rest of your application (or user base) can deal with. What’s not fine is just assuming that whatever functionality you happen to have in those areas is what you need, and yet that’s exactly what REST encourages people to do when the functionality is that of HTTP. Here, Mr. Client, I’ll give you a slice of my state, I might give overlapping slices to a bunch of other clients as well, any of you can come back with arbitrary changes at any time and I promise I won’t maintain any of the state necessary to validate those changes against one another (though I will do authentication because that’s the one lecture my authors didn’t sleep through). Sheer lunacy. At least Roy Fielding seemed/seems aware that his analysis of REST vs. alternatives was specific to a particular kind of application at a particular point in time, but many RESTafarians take a far less nuanced position. What’s truly amazing is when people with a thorough grounding in better concurrent/distributed programming models, like the actor model, promote the antithetical REST for common use. Really, sometimes REST is the right choice. Sometimes RPC is the right choice. Sometimes what you really want is server-driven notification requiring more context than either. The idea that all kinds of computer interaction in 2010 should be based on a protocol for serving static content to passive users in 1992 belongs in the dustbin of history.