[aerogear-dev] AeroGear Connectivity

Matthias Wessendorf matzew at apache.org
Thu Apr 11 07:55:32 EDT 2013


On Thu, Apr 11, 2013 at 1:44 PM, Kris Borchers <kris at redhat.com> 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 at apache.org>
> 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 :)



>
> 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-platforms>Supported
> 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-platforms-1>Supported
> 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 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/dc854ad9/attachment-0001.html 


More information about the aerogear-dev mailing list