On Apr 11, 2013, at 6:55 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Thu, Apr 11, 2013 at 1:44 PM, Kris Borchers <kris(a)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(a)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-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;
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-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