[SailfishDevel] Sending SMS Messages from Sailfish Alpha 2
"Thomas B. Rücker"
thomas at ruecker.fi
Fri Aug 9 21:29:23 UTC 2013
On 08/09/2013 10:24 PM, John Brooks wrote:
> On Aug 7, 2013, at 1:14 PM, Thomas B. Rücker <thomas at ruecker.fi> wrote:
>> let me join this conversation, as I have a similar use-case.
>> On 08/07/2013 06:19 PM, John Brooks wrote:
>>> On Aug 7, 2013, at 2:19 AM, christopher.lamb at thurweb.ch wrote:
>> My use case is related. I'm thinking about push notifications, generic
>> (although I have a specific use case too). As there is currently nothing
>> in that sense in Nemo/Sailfish I am pondering to base this on the XMPP
>> protocol, that's also available through Telepathy. Although technically
>> it could be interesting to be open to other protocols including SMS.
>> Here it would be good if my daemon could receive messages to a certain
>> Telepathy account and they would not appear in the UI, but would be
>> processed only by the daemon (e.g. triggering Feed events or dbus calls
>> or ...). In other situations it might be useful to listen in on messages
>> received by regular accounts though, too.
>> If you're wondering what prompted me to spin up this idea. I own a
>> Metawatch, a kind of smart watch, and want to use it with Sailfish/Nemo,
>> also to receive push notifications from my Irssi IRC client. This
>> currently works quite well with SOWatch under Harmattan already. Just
>> that the raw messages show up in the UI.
> Interesting idea! Using Telepathy for push notifications would be ideal, since it handles connectivity and would abstract the underlying protocol and server choice away. Here's what you could do:
> commhistory-daemon (https://github.com/nemomobile/commhistory-daemon) observes all Telepathy text channels and is responsible for notifications and logging. It would need to be modified to ignore channels for accounts with some property indicating that they shouldn't be user-visible. If I go through with my idea to make commhistory-daemon a handler instead of an observer, that could become much easier (because you could use an observer or approver to ensure that your own handler receives your channels, instead of commhistory-daemon).
> Then, you'd want to provide a Telepathy handler to receive and accept text channels on your notification account. That just takes a little bit of code with TelepathyQt, and could easily be exposed to allow handling from QML. You could also use TelepathyQt to create and manage the accounts used for notifications. If you install the right files (see https://github.com/nemomobile/qmlmessages/tree/master/data qmlmessages.client and org.freedesktop.*), you can even make sure that your daemon/application is launched automatically to handle them.
> It'd be interesting to see that idea developed into a push notification framework available to other applications. Keep me informed if you decide to pursue it ;)
Just a short reply right now.
Yes, the beauty would also be that if something more efficient as a
transport protocol becomes available, then you can just plug that into
Telepathy and be done with it. It has been argued that XMPP is not a
good protocol for this and is not power efficient. While I see this for
the generic use case (lots of bastardized XML going hence and forth for
every person in your list going online/offline/unavailable/...), this
could actually work much better for an isolated channel where there is
not much other traffic than keeping the TCP connection alive and the
actual data push from the server.
More information about the Devel