[aerogear-dev] AeroGear Connectivity

Thu Apr 11 09:10:45 EDT 2013

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

>
> On Apr 11, 2013, at 7:47 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Thu, Apr 11, 2013 at 2:25 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>
>>
>> On Apr 11, 2013, at 7: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 :)
>>
>>
>> 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,
>>
>
> "WEb Push" would be low-latency (since it's something over WebSocket),
> while w/ Device Push, we can't control it; the actual up to the network (so
> there is latency involved).
>
> Regarding "Web Push" - hey WebSocket exists for OBjC and Java as well :)
>
>
> But "Web Push" does not imply WebSockets to me which is why I find it
> confusing.
>

that's fine :) I don't really care about the names, but Web-Push was more
meaningful instead of "Foo Push" :)

>
> Regarding PubSub - if that library is build JUST on WebSocket/SockJS (not
> vert.x nor stomp.js), there is no pub-sub at all :)
>
>
> But I would see this library being built on top of vert.x or stomp.js or
> what ever. I am picturing Notifier to be the PubSub type thing where the
> Push stuff would be something else, AeroGear.Push or something like that.
>

+1 I am also not interested in doing plain Socket(SockJS/WebSocket).
Stomp.js (or vert.x) would offer a good amount of functionality (it's a
higher-level API). So, let's use that.

So, feel free to pick a good name :)

>
>
> So, that makes the name finding interesting :)
>
>
>
>
>
>
>>
>>
>>
>>
>>>
>>> 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
>> _______________________________________________
>> 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/4e5a3806/attachment-0001.html 