On Thu, Apr 11, 2013 at 3:05 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
On Apr 11, 2013, at 8:51 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Thu, Apr 11, 2013 at 2:28 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
>
> On Apr 11, 2013, at 8:07 AM, Kris Borchers <kris(a)redhat.com> wrote:
>
>
>
>
>> 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. 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.
>
>
> This could be very cool. Like an enterprise can have their own internal
> push network
>
I fear that mostly does not work :) You can only send messages to iOS, via
APNs; Similar to Android, where it has to go through GCM;
Providers like Urban Airship, accept the messages (for different networks)
and deliver them to APNs, GCM etc
>
>
> Would this be "built in"( maybe the wrong word) to controller?
>
Not sure what you mean here;
If we did create our own push network, webPush, would that be part of
controller somehow
I still don't understand :)
The Push Network (you want that as a separated server/service, for scaling
reasons) could be build with the controller…. (since it would a separate
server);
Do you want to integrate that "server" with the framework ? So if you use
controller for you app/routing, you always get the Push-Network? Hrm, I
guess I don't understand what you mean
>
>
>
>> 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
>
>
>
> _______________________________________________
> 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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf