On Sun, 30 Mar 2008, simon haywood wrote:
I'm expecting to see "pseudo push" type behaviour. I perceive the benefits of
this to be:
1. That emails will (should?) arrive to be read in my email client as soon as
they are sent - not after the next timed poll.
That assumes that there is infrastructure between the delivery system and
the IMAP server to accomplish that. That is not a good assumption.
If such infrastructure does not exist, then the server will poll
internally. That's what UW imapd does, at a one-minute interval.
I can't be overly sympathetic to people who can not wait a WHOLE MINUTE to
be told about delivery of a message that has taken goodness knows how long
to traverse the Internet SMTP infrastructure. SMTP based email is not IM;
there are IM protocols in the Internet protocol suite, and those protocols
should be used for IM purposes.
More to the point: even if I added the capability in dmail/tmail (UW
IMAP's delivery tools) to do a push that imapd immediately transmits, that
would not help the vast majority of UW imapd sites that do not use
dmail/tmail.
2. My MTA (Postfix) and desktop client (Apple Mail) both run on the same
machine. It seems daft for the machine to keep polling itself. I was looking
to find a less intensive solution.
If they run on the same system, why are you using IMAP? This question is
especially apt with Apple Mail, which clones the IMAP server mailbox
structure in its own private client store.
Polling accomplishes other purposes besides notification of new mail.
Even IDLE requires polling, albeit reducing it to a 29 minute cycle.
3. A step towards helping with general bandwidth and battery issues. I use a
mobile phone to connect to the server a lot - either in its own right, or as
a modem for the laptop.
IDLE is not sufficient for good mobile phone performance. You need quite
a bit more, or at least so the mobile phone people say. I find that
Alpine (which makes no concessions to mobile devices) on the Nokia N800
runs quite a bit better than mobile device clients that I've seen.
Yes, the iPhone Mail program has "ooh, shiny!"; but having spent hours
trying to analyze when its failure mode when it says "loading" and eats
battery for lunch, I'll stick with Alpine.
I have complete control over who and what connects to the server, and can
guarantee that Microsoft Outlook does not.
But what are you running on your mobile phone? I have yet to see ANY
mobile phone client that doesn't suck; and I've seen a lot of them.
I have read in the list archive about NAT issues - that's a bit of a blow I
agree! However, I was still hoping to try and make it work on the desktop -
to achieve the benefits of "instant delivery".
Why is it so important to you that you be notified "instantly" instead of
within a minute or so of delivery?
You seem not to be a fan of Idle! Am I over-estimating its benefits?
Yes, you are.
IDLE was a good idea that was defeated by technical reality. Internet
protocols are increasingly turning to "everything is stateless HTTP" which
is entirely client initiated. IMAP, being a Pull protocol, is client
initiated; but is highly stateful and uses reliable links. The HTTP world
assumes that if you don't get a response back quickly, you just drop the
connection and do a new one. HTTP might as well be based in UDP instead
of TCP.
Mobile phone push protocols depend upon an out of band signalling
mechanism which does not exist in the Internet protocol suite.
-- 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
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
