Re: [aerogear-dev] AeroGear Connectivity

On Apr 11, 2013, at 7:55 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Apr 11, 2013 at 1:44 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > I agree with most of this but have a few comments/suggestions inline. > > On Apr 11, 2013, at 4:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > AeroGear Connectivity > > The connectivity part in AeroGear (name: *AeroGear Connectivity Server*?) > is responsible to deliver messages from the server to the client. It > contains two *different* components: > > - Device Push > - Web Push > > I am not a fan of this naming. I feel like it is confusing. I think > Device Push should just be Push and Web Push should be something different > to show it is different. Maybe something simple like PubSub since that's > basically what it is. > Oh, yeah - as usually, I don't really care on names that much :) yea, i think something around PubSub for "Web Push" would be good. i got confused when i was reading the Web Push section, i was thinking why would we need android/ios libs when we can do Device push,

> > The *Web Push* offers a low-latency message deliver from the server to * > connected* clients, while the *Device Push* delivers notification-style > messages to an explict application, deployed on a mobile device. > <https://gist.github.com/matzew/17f793e4be11473423d2#device-push>Device > Push > > Push Notifications can be send to an explicit application (or even a > specific installation), deployed on a mobile device, wheter the application > is running or not. Push Messages are *not* intented to deliver large > messages, nor in a low-latency fashion. They are more notification-style > messages. The latency can not be controlled, since the actual message > delivery, to the phone, is controlled by the actual *Push Network*. > > The AeroGear server submits messages, for a certain mobile app, to such a > *Push Network* (like APNs or GCM). Different*Push Networks* have > different limitations and restrictions, regarding message size, etc. Most > *Push Networks* queue the message for offline devices (e.g. no > connection, no roaming or device switched off). Once they are back online > the message are delivered. Since these messages can become *stale* the *Push > Network* allow to specify an expiry time. > <https://gist.github.com/matzew/17f793e4be11473423d2#supported-client-plat... > client platforms > > Initially we are supporting the following platforms: > > - Android > - iOS > > *Note*: The above platforms includes hybrid containers, such as Apache > Cordova! > > In the future we may add support for more platforms, such as: > > - Firefox OS > - Blackberry > - Windows > > *NOTE*: One thing to have in mind, that there will be (eventually) a JS > API, which allows a server to deliver messages to a JS application, > deployed on any phone. *However*, it may take very long to get a unified > standard, that works accross the different devices. Platforms like Firefox > OS address this already, but only for one specific device type > > We can discuss this more in our meeting but I would like to suggest > implementing a JS SimplePush pollyfill now! We could follow this emerging > spec from FFOS (https://wiki.mozilla.org/WebAPI/SimplePush) which they > plan to implement in FF mobile and desktop later this year. > sounds good > We would need to build the server side piece into our unified push server > yup - that's not hard; it's similar to what we have for iOS and Android; It just uses a different PushNetwork to submit to; > bits but I think the effort would be worth it to provide a cross-browser > solution for push on the web which could be transitioned to the native > browser push when ready. > early on ! :)) sounds good! > <https://gist.github.com/matzew/17f793e4be11473423d2#web-push>Web Push > > The *Web Push* allows a low-latency message exchange between *connected* > (read: *online*) clients and the server. This is usually realized with > technologies like WebSocket (or robust fallbacks like SockJS). Once a > client application connects, it can exchange (receive and send) messages > with the server (and other clients). Messages have no restrictions in terms > of size of content (JSON, binary). While technoques like SockJS provide a > *socket connection* between the client and the server, it is desired to > have a more high-level API, to be used for the communication (e.g. Stomp). > > Initially, Clients that are offline are *NOT* receiving messages. > Messages are not persisted and stored, to be delivered later. > <https://gist.github.com/matzew/17f793e4be11473423d2#supported-client-plat... > client platforms > > - Android (Java client library) > - iOS (ObjC client library) > - JavaScript (JS client library, to be used in browsers and hybrid > containers) > > > Thoughts? The original gist is store here: > https://gist.github.com/matzew/17f793e4be11473423d2 > > -Matthias > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 _______________________________________________ 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