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.)
_______________________________________________
OpenMoko community mailing list
[email protected]
https://lists.openmoko.org/mailman/listinfo/community
