Re: moving mail between folders is intermittently failing
Dan White <[email protected]> Thu, 6 May 2010 03:19:24 -0500
| Newsgroups | gmane.mail.imap.uw.c-client |
|---|---|
| Message-ID | <[email protected]> |
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