On Apr 10, 2013, at 7:01 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wed, Apr 10, 2013 at 1:41 PM, Kris Borchers <kris(a)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
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