Thinking about Email Push

[paulkoan]

I have been playing with having a small script that connects to my imap server in imap-idle mode, then alerts me if there are new emails in various folders.

My email setup has new emails coming into folders other than INBOX, so this solves two problems: getting alerts for emails I am interested in, and removing the need to poll. And perhaps in PR1.2 the dbus call to send/recieve email will be fixed, which means the script could trigger the download too - and it would be great if this was a per folder call, but I doubt that it will be.

But it occurs to me that this is a less than optimal approach to push, as it requires a permanent data connection established. This is how iphone does it (albeit to Apple servers that act as a proxy to your email server) . S60 has an option for push via an SMS notification. This is "real push" in my mind, the notification comes out of band rather than across a data connection.

However, SMS isn't a cheap way to get a notification. It occurs to me that you could do something similar with a phone call. If the call isn't answered, it is a free signal.

I happen to have a spare voip number on my server, so I could have something checking the various folders on my email for new mails, when seen, tell my voip server to call my n900. The n900 would then detect the incoming call from a specific number, and issue an alert instead of answering the call - and issuing the dbus call to send-recieve email.

This whole setup wouldn't be useful to many people, but these are the fun things we can do with this phone, so they have to be tried.

So my question is - how can I detect an incoming call and trigger some action and prevent the phone app responding? CallBlocker does this somehow, so any ideas?

I was thinking it might be possible to monkey with the callerid of the incoming call too, to convey some information about what event is being signalled...

Paul

[sdpkom]

I have been playing with having a small script that connects to my imap server in imap-idle mode, then alerts me if there are new emails in various folders.

My email setup has new emails coming into folders other than INBOX, so this solves two problems: getting alerts for emails I am interested in, and removing the need to poll. And perhaps in PR1.2 the dbus call to send/recieve email will be fixed, which means the script could trigger the download too - and it would be great if this was a per folder call, but I doubt that it will be.

But it occurs to me that this is a less than optimal approach to push, as it requires a permanent data connection established. This is how iphone does it (albeit to Apple servers that act as a proxy to your email server) . S60 has an option for push via an SMS notification. This is "real push" in my mind, the notification comes out of band rather than across a data connection.

However, SMS isn't a cheap way to get a notification. It occurs to me that you could do something similar with a phone call. If the call isn't answered, it is a free signal.

I happen to have a spare voip number on my server, so I could have something checking the various folders on my email for new mails, when seen, tell my voip server to call my n900. The n900 would then detect the incoming call from a specific number, and issue an alert instead of answering the call - and issuing the dbus call to send-recieve email.

This whole setup wouldn't be useful to many people, but these are the fun things we can do with this phone, so they have to be tried.

So my question is - how can I detect an incoming call and trigger some action and prevent the phone app responding? CallBlocker does this somehow, so any ideas?

I was thinking it might be possible to monkey with the callerid of the incoming call too, to convey some information about what event is being signalled...

Paul

I have no answer to your question, but...
1. Can you publish your script?
2. Google voice allows free SMS (to the US and many countries), there might be an API to use this within an application.

[TA-t3]

I too would be interested in that script.. it would solve a couple of use-case problems I have with the current email support.

[paulkoan]

It isn't a script in the sense that you can use it for anything, just poc. But once it does something I will certainly put it out there for someone to run with.

I got hold of a google voice account so SMS is an option too. The question is, how can I detect an incoming call / SMS and act on it in preference to the phone app? Ie, I would need my app to deal with it and the phone app not even see it.

[juise-]

But it occurs to me that this is a less than optimal approach to push, as it requires a permanent data connection established.

Do you actually know that having an open data connection consumes any more power than just being on the cell network, listening for incoming calls/SMS/push notifications? I don't know much about how the 3G link layer stuff works, but I haven't been able to measure a difference in battery life (which is the only thing I can see being subject to optimization here).

At least a TCP connection, once opened, doesn't transmit anything unless there's some real data to be put through the connection.

[qwazix]

Do you actually know that having an open data connection consumes any more power than just being on the cell network, listening for incoming calls/SMS/push notifications? I don't know much about how the 3G link layer stuff works, but I haven't been able to measure a difference in battery life (which is the only thing I can see being subject to optimization here).

At least a TCP connection, once opened, doesn't transmit anything unless there's some real data to be put through the connection.

A permanent data connection on a device like the N900 is a dangerous thing for people without a proper data plan. I can't find a way to make sure that nothing communicates through the connection and the prices per KB are super-high. Also the unanswered call thing is completely free whether you got a plan or not.
________
Avandia help (http://www.classactionsettlements.org/lawsuit/avandia/)

[paulkoan]

Do you actually know that having an open data connection consumes any more power than just being on the cell network, listening for incoming calls/SMS/push notifications? I don't know much about how the 3G link layer stuff works, but I haven't been able to measure a difference in battery life (which is the only thing I can see being subject to optimization here).

At least a TCP connection, once opened, doesn't transmit anything unless there's some real data to be put through the connection.

Yeah, well the received wisdom here is that having 2G/3G running consumes battery. I haven't tested this for myself, but certainly having dual mode enabled means that the continual scans for 3G in spotty coverage areas uses a lot of battery.

I tend to shift my radio to 2G only through out the day - which means for me, IMAP-IDLE is enough.

However the idea of using SMS as a notification system is interesting - you might use this for any number of purposes - provided the SMS can be captured before Conversations gets it.

[daperl]

All things dbus are open source. You can make your own switchboard if that is your wish. I don't know about rejecting SMS though, but it certainly would be cool if they could be read and rejected. Here in the States we're doubly blessed with being charged for incoming SMS.

[paulkoan]

Do they still double-dip and charge for incoming calls as well?

The last thing left in AU and UK is charging to both leave and receive voicemails, but there are some UK networks that provide voicemail for free.

So... you are saying that dbus is the thing that routes the incoming SMS to Conversations? Do you have any more info?

[daperl]

Do they still double-dip and charge for incoming calls as well?

Yes, the minutes are counted against in both directions.

receive voicemails

Charged for receiving voicemails? That's like being charged for a missed call. Poor.

So... you are saying that dbus is the thing that routes the incoming SMS to Conversations? Do you have any more info?

Yes, that's what I'm saying. It seems that all interprocess communication and monitoring is done through the dbus. Most of the API's have wrapper functions for the dbus stuff. You want to go down these two rabbit holes here:

http://maemo.org/api_refs/5.0/5.0-final/telepathy-glib/
http://maemo.org/api_refs/5.0/5.0-final/eventlogger/index.html

And here's the full API page:

http://maemo.org/development/sdks/maemo_5_api_documentation/

I've already done some preliminary work, but I'm fully diving-in this weekend. I have a POC for a conversation thread window that supports rotation. These are next on my list:


Conversation thread-list window (in progress)
Proper HIM rotating keyboard (very preliminary)
Sending and receiving messages through proper channels (still researching)

I'll post progress here, as well as my other usual Conversations hacking locations. And I encourage others to do the same. These API's are going to be with us for some time, and I would venture to say that glib and gobject will be coming along also, regardless of the UI platform.

And lastly as a sidenote, ALL the Maemo API'S should be of interest. Before wandering into this Conversations stuff, I was in the process of mimicking/enhancing the mediaplayer. Again, the MAFW API seems solid, and the tracker tie-in with all these things is cohesive. Dig in.

But in the end, Push is where the gold is. Sermon over.