4:42 a.m.
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(a)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(a)redhat.com> wrote:
>
> On Apr 10, 2013, at 11:15 AM, Douglas Campos <qmx(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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