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