[aerogear-dev] Non-Native Push Discussion

[Matthias Wessendorf]

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 at 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 at redhat.com> wrote:
>
> >
> > On Apr 10, 2013, at 11:15 AM, Douglas Campos <qmx at 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 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/20130411/0b1784fc/attachment-0001.html