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