Hello Kris,

as already mentioned on the IRC; for "connectivity" we basically have two (totally) different things:

* device push (e.g. Android, iOS and something like the W3C Push-API (if that ever will happen)) to push notifications to devices;
* online/web messaging: connected clients (Android, iOS or JS clients) exchange messages, with also zero latency. The messages can be large - really large, if desired :)

One thing.... Not sure how the NNP (None-Native-Push) wording fits into one of these two categories; For me, a JS push api, that eventually runs on every phone/browser would be in that "native" push category (since the messages are submitted to a PushNetwork, which ensure the messages is, eventually, delivered to a device);
For me, the device is the "native container", that receives the messages and delivers it to the matching app therefore I used the "device push" above.

Client Apps that require a persistent connection, for low-latency "message" exchange, are also both: native: (Android/Java, iOS/ObjC,...) and none-native: JS; However, here it's not the phone that "dispatches" the incoming messages. The app connects and inside of the app, it receives it - the actual OS is not responsible to give the received payload, from a socket, to an actual app.

I wrote a little gist, posted on a different thread ("AeroGear Connectivity") :) 

-Matthias



On Wed, Apr 10, 2013 at 9:50 PM, Kris Borchers <kris@redhat.com> wrote:
After some initial research into the Web Notifications API, Push API and a discussion with qmx, I think we should hold off on any work regarding NNP and the JS notifier implementation until further notice. I need to do a lot more research into what work is going on out there in the browsers and where we made need to get involved or poke the right people to get involved to have a proper spec to go off of. I will try to get a writeup of my research in the next days so we can have a proper discussion about this before moving forward.

On Apr 10, 2013, at 11:32 AM, Kris Borchers <kris@redhat.com> wrote:

>
> On Apr 10, 2013, at 11:15 AM, Douglas Campos <qmx@qmx.me> wrote:
>
>> On Wed, Apr 10, 2013 at 06:41:20AM -0500, Kris Borchers wrote:
>>> ## 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.  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.
>>
>> How does the Push API[1] fits here?
>
> I need to read this spec more thoroughly (which I am doing now) but we should probably follow it for easier integration when browsers actually start to support this stuff natively.
>>
>> [1]:http://www.w3.org/TR/push-api/
>>
>> --
>> qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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