[Standards] Comments on the Push XEP
Hi everyone, Following up on the message by Lance asking for comments on https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md, I've come up with a couple of suggestions/questions. * I still think it's valid to allow a component to proxy more than one proprietary push service. Although the XEP says "XMPP servers MUST NOT be limited by the protocol to support push notifications for only a single client app or proprietary push service", I couldn't figure out how to do this in this XEP. My thinking is that the component could be configured with a default push service, which would fit the scenario where a single proprietary push service is proxied, and then, in the register stanza, we could have something like: gcm|email|... In this sense, we would also need to query for the available push services. * Sometimes we need specific information from the proprietary push service in order to subscribe to their notifications. For instance, in order to register on a GCM project, we need the GCM project id in the client side. In the buddycloud pusher, we achieve that by sending a http://buddycloud.com/pusher/notification-metadata stanza to the pusher. This stanza returns information on a specific push type which is required for the client to subscribe to its notifications. I think we need something similar to that in this XEP. BTW, the XEP is coming out great. Thanks to everyone involved. I'm looking forward to making the buddycloud pusher compliant to this. Regards, Abmar -- 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
Re: [Standards] Push notifications
A single buddycloud push server is able to send notifications to different types of push services (email, GCM, SMS, etc.). Hope the XEP complies with multi-push-service requirements. That means more flexibility implementation-wise, and doesn't mean we can't have single-push-server components by having, for instance, a default type setting. On Fri, Jan 31, 2014 at 11:34 AM, Daniele Ricci wrote: > I wish I was there... :-( > I'll reply to Lance mail as soon as I find 10 minutes straight (thank > you for your very clear picture of the XEP by the way). > > On Fri, Jan 31, 2014 at 11:32 AM, Simon Tennant > wrote: > > Interesting conversations about push today. > > > > This is how we do it (curently) at buddycloud to send "someone followed > you" > > "new posts in your channel" etc. > > > > https://github.com/buddycloud/buddycloud-pusher/blob/master/README.md > > > > Keen to standardise. > > > > S. > > -- > > Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: > > goo.gl/tQgxP > > > > -- > 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
Re: [Standards] Push notification XEP
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 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: > > >node='http://jabber.org/extensions/presence#push'> > > > > > > > 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: > > > ... > ... > REGISTRATION-ID > > > (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: > > > DEVICE-TOKEN > > > 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
