[aerogear-dev] Non-Native Push Discussion

Wed Apr 10 09:13:42 EDT 2013

+ Firefox OS

On Wed, Apr 10, 2013 at 2:45 PM, Kris Borchers <kris at 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 at redhat.com> wrote:
>
>
> On Apr 10, 2013, at 7: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))
>
>
> 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-filtered-list-of-users-installations
>
>
> 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 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
>
>
>
> _______________________________________________
> 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/fa67c564/attachment-0001.html 