[aerogear-dev] AeroGear Connectivity

Thu Apr 11 08:59:33 EDT 2013

On Thu, Apr 11, 2013 at 2:07 PM, Kris Borchers <kris at redhat.com> wrote:

>
> On Apr 11, 2013, at 6:55 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> 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;
>
>
> The problem is that push network doesn't exist either and I don't want to
> wait for the browsers to build them :) … we would need to build that as
> well.
>

So we build a push-network for all the mobile phone's browser/JS push
facility ?

> What I am thinking is we would build the network into our server side so
> that users could deploy their own PushNetwork for their apps but have the
> ability for the clients to use the appropriate browser PushNetwork if
> available. Then, we would eventually kill our PushNetwork bits when all
> browsers implement their own.
>
>
>
>> 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
> _______________________________________________
> 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/16fc146f/attachment.html 