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)) 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... 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) 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 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

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))

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...

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)

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

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

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

+1 to FireFox OS, although that should just work On Apr 10, 2013, at 9:13 AM, Matthias Wessendorf <matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > + Firefox OS > > > On Wed, Apr 10, 2013 at 2:45 PM, Kris Borchers <kris(a)redhat.com (mailto:kris@redhat.com)> wrote: > > 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 (mailto:kris@redhat.com)> wrote: > > > > > > On Apr 10, 2013, at 7:01 AM, Matthias Wessendorf <matzew(a)apache.org (mailto:matzew@apache.org)> wrote: > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 1:41 PM, Kris Borchers <kris(a)redhat.com (mailto:kris@redhat.com)> 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 (mailto:aerogear-dev@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 (mailto:aerogear-dev@lists.jboss.org) > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@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 (mailto:aerogear-dev@lists.jboss.org) > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Apr 10, 2013 at 06:41:20AM -0500, Kris Borchers wrote: > ## 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. 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. How does the Push API[1] fits here? [1]:http://www.w3.org/TR/push-api/

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Apr 10, 2013, at 11:15 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > On Wed, Apr 10, 2013 at 06:41:20AM -0500, Kris Borchers wrote: >> ## 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. 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. > > How does the Push API[1] fits here? I need to read this spec more thoroughly (which I am doing now) but we should probably follow it for easier integration when browsers actually start to support this stuff natively. > > [1]:http://www.w3.org/TR/push-api/ > > -- > qmx > _______________________________________________ > 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

Hello Kris, as already mentioned on the IRC; for "connectivity" we basically have two (totally) different things: * device push (e.g. Android, iOS and something like the W3C Push-API (if that ever will happen)) to push notifications to devices; * online/web messaging: connected clients (Android, iOS or JS clients) exchange messages, with also zero latency. The messages can be large - really large, if desired :) One thing.... Not sure how the NNP (None-Native-Push) wording fits into one of these two categories; For me, a JS push api, that eventually runs on every phone/browser would be in that "native" push category (since the messages are submitted to a PushNetwork, which ensure the messages is, eventually, delivered to a device); For me, the device is the "native container", that receives the messages and delivers it to the matching app therefore I used the "device push" above. Client Apps that require a persistent connection, for low-latency "message" exchange, are also both: native: (Android/Java, iOS/ObjC,...) and none-native: JS; However, here it's not the phone that "dispatches" the incoming messages. The app connects and inside of the app, it receives it - the actual OS is not responsible to give the received payload, from a socket, to an actual app. I wrote a little gist, posted on a different thread ("AeroGear Connectivity") :) -Matthias On Wed, Apr 10, 2013 at 9:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: After some initial research into the Web Notifications API, Push API and a discussion with qmx, I think we should hold off on any work regarding NNP and the JS notifier implementation until further notice. I need to do a lot more research into what work is going on out there in the browsers and where we made need to get involved or poke the right people to get involved to have a proper spec to go off of. I will try to get a writeup of my research in the next days so we can have a proper discussion about this before moving forward. On Apr 10, 2013, at 11:32 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Apr 10, 2013, at 11:15 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >> On Wed, Apr 10, 2013 at 06:41:20AM -0500, Kris Borchers wrote: >>> ## 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. 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. >> >> How does the Push API[1] fits here? > > I need to read this spec more thoroughly (which I am doing now) but we should probably follow it for easier integration when browsers actually start to support this stuff natively. >> >> [1]:http://www.w3.org/TR/push-api/ >> >> -- >> qmx >> _______________________________________________ >> 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 -- 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