On 06/05/10 09:22 +0200, Oswald Buddenhagen wrote:
On Wed, May 05, 2010 at 03:09:20PM -0700, Mark Crispin wrote:
On Wed, 5 May 2010, UCTC Sysadmin wrote:
>If they can understand the difference between TCP and UDP, they can
>understand state.
I wouldn't be so certain. If you look at a lot of applications these
days, they blat out a query, and read an answer. If they don't get an
answer in what they consider to be a suitable time, they drop the
connection and try again.
Put another way, they treat TCP just like UDP, only with this strange and
annoying "connection" stuff that they don't understand why it's there.
you may rail about the stupidity of those developers as much as you
want. apparently unlike you, they live in the real world where the only
guarantee which tcp provides is that the data stream is intact - *if* it
arrives. timeouts as a workaround for shortcomings of the tcp/ip stack
under real-world conditions are a perfectly reasonable approach, just
like keep-alive signals in higher-level stateful protocols to prevent
timeouts. if you want to do better, you can use imap directly over ATM
or ISDN or other really stateful protocols. but even these sometimes
just go deaf, because they run with crappy real-world system software,
too.
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?
What if, while the server is chugging away at one query, the user of your
application clicks on another message while your application is waiting for
a response from the server? Do you send another query? hang the interface
until the first completes? Kill the imap connection and forget the first
task? Cache and retry?
Treating an IMAP *session* like a stateless http request is doomed to
repeat history. RFC 2683 covers some of this ground.
--
Dan White
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
