[aerogear-dev] AeroGear Connectivity

Matthias Wessendorf matzew at apache.org
Thu Apr 11 09:14:30 EDT 2013


On Thu, Apr 11, 2013 at 3:09 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Thu, Apr 11, 2013 at 2:58 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Thu, Apr 11, 2013 at 2:34 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Apr 11, 2013 at 2:28 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>>>
>>>>
>>>> On Apr 11, 2013, at 8:07 AM, Kris Borchers <kris at 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
>>>>
>>>>
>>>> Would this be "built in"(  maybe the wrong word) to controller?
>>>>
>>>
>>> Well, maybe I'm wrong but with all the specs that Matthias did we have
>>> 90% of the bits , the 10% being a custom implementation of the Sender API,
>>> no ?
>>>
>>
>>
>> I have no clue what you mean;
>>
>
> :)
> For the scope, 100% web, no hybrid : in your gist you define "web push",
> where we offer a convenient library for doing "atomic" push operations :
> online chat, multiplayer game. But we could image to offer for the Web the
> same infrastructure (same API, concepts not same impl) as you defined for
> the Native Push : with Registry etc ... It will be a "degraded" service
> since pushing of notification will only be possible when online but still I
> think there can be demand for that.
>


That's already there:
https://github.com/matzew/ag-up-poc#web-app

but I guess we are getting rid of that for the "pub/sub" (web push), which
is the original motiviation of Kris' email - and I was also not too happy
with that "100% Web" integration on the push server;


-Matthias




>
>
>
>
>
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/afb5a43d/attachment.html 


More information about the aerogear-dev mailing list