Re: [aerogear-dev] Non-Native Push Discussion

Something else I just thought of. Even though we don't support them now, should we at least be taking into account the implications of integrating native push for Windows Phone and/or Blackberry? On Apr 10, 2013, at 7:23 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Apr 10, 2013, at 7:01 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Wed, Apr 10, 2013 at 1:41 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Hey all, > > So I wanted to start thinking about the spec and APIs that will be used > for non-native push notifications. In order to do that, I first wanted to > just throw my understanding of things and some very preliminary initial > thoughts out there for discussion so we are all on the same page before any > implementation begins. I have written those thoughts in this gist > https://gist.github.com/kborchers/694f09159e85d861cf3b and have also > pasted the contents of that gist below to provide easier inline comments > and discussion. > > Thanks! > > > > #Non-Native Push (NNP) > > The ability to "push" messages to a JavaScript client is an interesting > yet complicated problem to solve. There are a number of factors to take > into account. Below is a summary of some of those factors and thoughts on > how to address them. > > ## NNP vs. Notifier > > I first want to address the idea of NNP vs. Notifier as a whole. The way > I see it, NNP is an adapter in the grand Notifier scheme. Notifier would be > the umbrella object that would be a factory for generating notifier clients > based on different adapters. There could be adapters for vert.x (thinking > about renaming that adapter to SockJS since that's more what it is I > believe), > nope, it's not; SockJS is plain/primitive socket (=== WebSocket); While vert.x is a pub/sub bus (=== Stomp(.js)) Oh, right. I wonder if we should, at some point, be interested in creating adapters that are not pub/sub and can work on raw sockets as well. Just a thought. > Atmosphere, or for purposes of this discussion, NNP. > > ## Server Side > > On the server side, the NNP bits should be flexible. Since there is no > defined method for sending a NNP message to a client like there is for > native implementations like iOS and Android, the NNP parts should be > flexible enough to work in tandom with those native bits. It should also be > possible to send messages to only NNP clients, only native clients (both > all native or by OS), > Right, we (somewhat) defined already an API to send message to a specific variant (iOS, Android, Web), or broadcast or what not: https://gist.github.com/matzew/b21c1404cc093825f0fb#send-message-to-a-fil... Yep, that makes sense … I think ;) > all client types, or individual clients of a particular registered app. > It would also be nice to be able to send NNP messages to individual devices > "devices" for web that would be "users" (identified by ID (userID / sessionID)) - on the native side there is more a device (since we have tokens to identify an app, on device) Correct, individual users is what I meant. Either way, we still need some way of individually identifying them without any possibility of overlap for individual messages. > which should be possible through either some sort of authentication > system or via individual channels of currently connected clients. Another > nice feature to have would be the ability to queue messages for NNP clients > that are not currently connected. This would involve determining some > method for message prioritization as well as expiration to avoid extremely > long and/or oudated message queues. > yes, would be nice to have a persistent store > These messages could then be delivered when a particular client "phones > home" either through the previously mentioned authentication method or > channel subscription. > > ## Client Side > > The client will also be very flexible in relationship to native push. > Again, since there is no real standard for NNP, the client should be built > to accept what ever unified payload is designed to work for the native > push. That way this will again provide for seamless integration with the > unified push. > Message thoughts in here: https://gist.github.com/matzew/b21c1404cc093825f0fb#message-format Yep, I just wasn't sure if those formats were final so I wanted to bring that discussion back up to verify. The format is very important to the non-native client because I actually may have to process the push message myself to provide it in a way that makes sense to the JS dev. Maybe not but would like that format defined and finalized before I start working. > The client will be built as an adapter of Notifier allowing an AeroGear > user to manage all notification messaging (Push, Pub/Sub, etc) in one > place. This means that the spec and APIs for Notifier need to be decided > and documented before or at the same time as the NNP is being developed. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev