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

[Elliot F.]

Redvers Davies wrote:
> On Tue, 2007-01-30 at 23:49 -0800, Elliot F. wrote:
>> Google talk has a persistent connection between the client and the 
>> server.   With a persistent connection, pushing data is pretty easy.
> 
> We have to use a persistant connection as most GSM networks use private
> address space and NAT.  This means we can't just throw a UDP packet at
> the phone.

I realize we can't make unsolicited connections to the phone, but I 
would disagree with the "we have to use a persistent connection" 
statement.  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.

> IMAP is an asyncronous protocol.  The purpose of the IDLE command is
> JUST to spot the IMAP server tearing down the connection.  IDLE is not a
> poll, if configured correctly the IMAP server will just spit out
> notifications on the existing TCP stream as and when mails come in.

I'm not sure what you mean by "IMAP is an asynchronous protocol", but I 
never said that IDLE was a poll.  It's also not there "JUST to spot the 
IMAP server tearing down the connection."  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

Another good summary of the whole topic is here: 
http://www.isode.com/whitepapers/imap-idle.html

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.

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.  If anyone wanted to 
implement the openmoko stack as a hardwired application (using VOIP for 
making/taking phone calls, for example), then the persistent connection 
would make much more sense.

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.)