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