The Buddycloud pusher approach is - Run as a component - be generic: don't care about the specific push service (email, Google, Apple, next-big-thing) - Give users a way to enable/disable it - Advertise it as a service using SRV records (virtual host for other domains that don't want to run a full push service)
Would be nice to think about how push notifications could work with some of the SIFT specs. Eg: a new <message> would trigger a push, wake an Android App, sync, kill connection, go back to not keeping an open connection. Daniele - will you be at the Summit? S. On 21 January 2014 11:53, Steffen Larsen <[email protected]> wrote: > Yes but the approach that this bodycloud component (XEP-0114) could easily > be written into more or less a XEP. > > /Steffen > > On 21 Jan 2014, at 11:51, Daniele Ricci <[email protected]> wrote: > > > I was thinking of a more specific (and simpler) approach to just using > > push notification services. Buddycloud is much more than that. > > > > On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros <[email protected]> > wrote: > >> It sounds like what we've been doing with the buddycloud pusher: > >> https://github.com/buddycloud/buddycloud-pusher. > >> > >> We currently use it to send GCM and emails regarding buddycloud-related > >> events, as per its documentation, but it can be easily extended to push > any > >> XMPP event to any pusher service, eg.: Apple's, SMS. > >> > >> Regards, > >> Abmar > >> > >> > >> On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci < > [email protected]> > >> wrote: > >>> > >>> Hello list, > >>> I was thinking of writing a XEP for sending a sender ID (Google Cloud > >>> Messaging) or a device token (Apple Push Notification Service) or any > >>> other push notification service token (that is, a generic one) to the > >>> server. > >>> Almost all push notification services works the same way: the server > >>> provides a provider ID to the client and the client provides a device > >>> token to the server. > >>> > >>> I was thinking of using service discovery to advertise the service > >>> from a server: > >>> > >>> <iq from='example.com' type='result' id='H-2' to='[email protected]'> > >>> <query xmlns='http://jabber.org/protocol/disco#items' > >>> node='http://jabber.org/extensions/presence#push'> > >>> <item node='SENDER-ID' jid='gcm.push.example.com' name='Google > >>> Cloud Messaging'/> > >>> <item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple > >>> Push Notification Service'/> > >>> <item ... /> > >>> </query> > >>> </iq> > >>> > >>> In the "node" attribute I'd put the provider ID I was talking about > >>> earlier. > >>> > >>> Device token could be sent using a presence update from the client: > >>> > >>> <presence> > >>> <status>...</status> > >>> ... > >>> <c xmlns='http://jabber.org/extensions/presence#push > >>> provider='gcm.push.example.com'>REGISTRATION-ID</c> > >>> </presence> > >>> > >>> (that would need to be filtered by the server before broadcasting the > >>> presence update though, for security reasons). > >>> > >>> Or an iq to the push notification address could be used: > >>> > >>> <iq to='gcm.push.example.com'> > >>> <token > >>> xmlns='http://jabber.org/extensions/presence#push > '>DEVICE-TOKEN</token> > >>> </iq> > >>> > >>> I'd really appreciate some feedback. I think it would be a useful XEP. > >>> Regards, > >>> -- > >>> Daniele > >> > >> > >> > >> > >> -- > >> Abmar Barros > >> MSc in Computer Science from the Federal University of Campina Grande - > >> www.ufcg.edu.br > >> OurGrid Team Leader - www.ourgrid.org > >> Buddycloud Dev - www.buddycloud.org > >> Paraíba - Brazil > > > > > > > > -- > > Daniele > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
