On 08/09/2013 10:24 PM, John Brooks wrote: > On Aug 7, 2013, at 1:14 PM, Thomas B. Rücker <tho...@ruecker.fi> wrote: > >> Hi, >> >> 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.l...@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. Cheers Thomas _______________________________________________ SailfishOS.org Devel mailing list
