Andreas Kostyrka wrote:
* Elliot F. <[EMAIL PROTECTED]> [070131 03:45]:
Or you could simply modify the mail server to trigger a script when a message is delivered, rather than having to poll each directory/file. A procmail/maildrop filter would be one way
to implement it easily (allowing you to filter for messages from specific people, to certain folders, etc.)
With the specific problem that you have nowhere to push to. Normal
GPRS has to live with a strict NAT firewall. That's (and because of
billing aspects) probably why pushmailservices usually have their own
APN.
My point was that the mail server (MDA, as I was suggesting with
procmail) would trigger the event that notifies the phone client that a
new message arrived. I wasn't suggesting that the server is going to
connect to port 1025 on the phone and deliver via SMTP. :) The client
would be notified and pull any new messages.
I really like this idea. As I understood it, many previous "push email" services relied on sending an SMS message to the phone, which made the phone perform the actions that you
describe (get new mail.) However, hooking in directly to the incoming call would save the money that SMS messages cost.
Nope, real push mail is just that. It just needs support from the
network. Or a special low bandwidth protocol to poll.
E.g. one of the highest prices mentioned here was 1KB at 3cent (CDN).
Still, one could design a protocol that sends one "I'm alive byte" say
30 minutes, and listens all the time for an "you've got mail byte".
Don't forget protocol overhead. UDP header alone is 8 bytes, plus IP
header, and it doesn't get much more lightweight than that. Of course,
you won't know if the packet actually made it to the destination. :)
That would mean, a standby cost of 1KB every 20 days. That's assumming
a keep alive is needed every 30 minutes. Guess it would make sense to
support an additional mode where (for the home network) the phone
senses the right standby before the NAT firewall kills our TCP
connection. (But that should be manual, because the reconnects needed
during probing will use up some KB)
Why bother polling at all? You would be repeatedly starting up or
maintaining a data connection when there may/may not be a need. I'm not
sure, but I would assume it would also use more power while maintaining
the connection (due to the radio.) Why not use some sort of method to
notify the client when there is a message (via SMS or call from a known
number)?
I'd be interested in seeing/hearing what hooks/services will be exposed. Will
the incoming calls trigger a dbus message or something similar?
5. skript2 will switch on GPRS and fetch the new
mail via POP or IMAP
and after downloading the mail it will inform
the user (depend on the dailingprofil)
So did I missed something? Why is push services
and the software for this such a hype?
Yeah, the original poster missed the fact, that in most billing plans
switching off GPRS is expensive. E.g. GPRS is billed usually in blocks
of 10/100KB (this applies btw also to xMB included plans in Austria).
So switching off GPRS while you've fetched a 2KB email is plain stupid.
There's no reason to be insulting. Please try to be respectful and
educate rather than insult. Besides, I don't think turning on GPRS
and/or leaving it on to poll is any better. You're wasting battery life
and data with maintaining a persistent connection/polling. Also, I
believe that voice calls cannot be received when a data connection is
active. Please correct me if I'm wrong.
Getting a call from a known number and not having the phone ring is free
in most places. It's free, doesn't take much battery life, and doesn't
spend data by polling. That is the best part of Robert's idea.
Because it's very handy, and very well integrated. Blackberry and Windows
Mobile (or whatever it's called) have the pieces at both ends that are required
for the integration.
Yeah, and the support of the network providers ;)
Which isn't strictly necessary.
_______________________________________________
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community
