<div dir="ltr">Hello Kris,<div><br></div><div style>as already mentioned on the IRC; for "connectivity" we basically have two (totally) different things:</div><div style><br></div><div style>* device push (e.g. Android, iOS and something like the W3C Push-API (if that ever will happen)) to push notifications to devices;</div>
<div style>* 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 :)</div><div style><br></div><div style>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);</div>
<div style>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.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>I wrote a little gist, posted on a different thread ("AeroGear Connectivity") :) </div><div style><br></div><div style>-Matthias</div><div style><br></div><div><br></div><div><br>
</div><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 10, 2013 at 9:50 PM, Kris Borchers <span dir="ltr"><<a href="mailto:kris@redhat.com" target="_blank">kris@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<div class="HOEnZb"><div class="h5"><br>
On Apr 10, 2013, at 11:32 AM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br>
<br>
><br>
> On Apr 10, 2013, at 11:15 AM, Douglas Campos <<a href="mailto:qmx@qmx.me">qmx@qmx.me</a>> wrote:<br>
><br>
>> On Wed, Apr 10, 2013 at 06:41:20AM -0500, Kris Borchers wrote:<br>
>>> ## Client Side<br>
>>><br>
>>> The client will also be very flexible in relationship to native push.<br>
>>> Again, since there is no real standard for NNP, the client should be<br>
>>> built to accept what ever unified payload is designed to work for the<br>
>>> native push. That way this will again provide for seamless integration<br>
>>> with the unified push. The client will be built as an adapter of<br>
>>> Notifier allowing an AeroGear user to manage all notification<br>
>>> messaging (Push, Pub/Sub, etc) in one place. This means that the spec<br>
>>> and APIs for Notifier need to be decided and documented before or at<br>
>>> the same time as the NNP is being developed.<br>
>><br>
>> How does the Push API[1] fits here?<br>
><br>
> 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.<br>
>><br>
>> [1]:<a href="http://www.w3.org/TR/push-api/" target="_blank">http://www.w3.org/TR/push-api/</a><br>
>><br>
>> --<br>
>> qmx<br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>