[aerogear-dev] Non-Native Push Discussion

[Matthias Wessendorf]

On Wed, Apr 10, 2013 at 1:41 PM, Kris Borchers <kris at 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-filtered-list-of-users-installations



> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130410/c828e674/attachment.html