On Apr 11, 2013, at 7: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 :)
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.
>
> 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). DifferentPush 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.
>
> 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!
> 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.
>
> 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(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