Email Push Service :) smtp+dnotify+Asterisk+... :)

Redvers Davies openmoko at unixfu.com
Thu Feb 1 10:41:40 CET 2007


On Wed, 2007-01-31 at 16:14 -0800, Elliot F. wrote:
> The best point that Robert made in his original post was 
> that there are out of band methods of alerting the phone that a new 
> message is available (call from known number or SMS message.)  As far as 
> I know, this is how current "push" email systems work.

I agree.  Any potential method of notification should be explored since
different carriers bill different features at different rates.

> I'm not sure what you mean by "IMAP is an asynchronous protocol",

By that I mean that answers / notifications from an IMAP server do not
have to be returned in the order in which you send them.

IE, if you make 3 requests the protocol allows the results from those
requests to return in any arbitrary order plus of course the possibility
of additional notifications which you don't explicitly request.

> but I 
> never said that IDLE was a poll.

I did not intend to infer that.  I was wanting to clarify what I read to
be slightly ambiguous.

> It's also not there "JUST to spot the 
> IMAP server tearing down the connection."

I typoed.  s/spot/stop/

It's there to stop the IMAP server closing the connection as IDLE.  I'd
prefer they used NOOP but I didn't author the protocol :-P

> IMAP IDLE is 'true' push 
> email (at least the earliest I know of.)  IMAP maintains a persistent 
> connection to a server (see my comment above re: "pushing data is easy 
> with a persistent connection.)  The server can then push messages via 
> the established connection.  For those interested: 
> http://www.faqs.org/rfcs/rfc2177.html

Absolutely.

> My whole point is that maintaining a persistent connection between the 
> mobile phone is (in my opinion) not efficient, not as easy, and more 
> prone to error than using some sort of out-of-band notification.

Well, the IDLE interval required is going to be dependent on the IMAP
server and carrier (you can be sure they time-out "idle" tcp sessions
through their NAT gateways).

Whether it is efficient or not on this platform is a financial choice.
For example, I have unlimited data on my plan but I am charged per SMS
(Cingular USA).

SMS would be expensive for me as a notification mechanism.

As for initializing calls, I saw a company "abuse" ISDN bandwidth that
way by encoding within ISDN signalling.  A fully functional but low
bandwidth connection without a single phonecall made.

> I'd be happy to see all implementations, though.  There's not reason why 
> it needs to be done just one way.  Depending on the user, it may make 
> more sense to do it one way over the other.

I agreee 100%.

> I think I'll leave this thread now, as it doesn't seem to be bearing 
> much fruit.  I look forward to the SDK and the phone, though, as this is 
> a very promising feature (as anyone who is a blackberry addict can attest.)

Later.



Red






More information about the community mailing list