[aerogear-dev] Non-Native Push Discussion

Wed Apr 10 08:15:16 EDT 2013

On Wed, Apr 10, 2013 at 2:10 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:

>
> On Apr 10, 2013, at 8:01 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> 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
>
>
> this is more an implementation detail,  but we could probably leverage
> infinispan here, it has eviction policy stuff
>

I'd prefer more something like druable queues/topics (->JMS); not sure how
the cache would fit in there, for real persistence)

>
>
>
>
>>  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
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> 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/c072f8b4/attachment.html 