2012/12/18 Matthias Wessendorf <matzew@apache.org>

On Tue, Dec 18, 2012 at 12:46 PM, Daniel Manzke
<daniel.manzke@googlemail.com> wrote:
> nothing to do with your case, but just my two cents. don't invent another
> library to wrap it up. use atmosphere instead ;)

well, main focus here is offering client APIs and client functionality.

On the server side there will be just a light/tiny/thin layer around
an _existing_ WebSocket server. Most-likely JSR 356 implementation.
If Atmosphere comes with an impl of that (I think the want to do
that), it could be used. Or what ever the underlying container uses.

Similar to our REST "extensions"

Also, outside of the JavaEE realm, we wanna make sure that things like
Netty (read: protocol servers) can be hooked in as well.

Don't worry, nobody is writing yet another WebSocket server here

Cheers!
Matthias

[1]

>
>
> 2012/12/17 Jay Balunas <jbalunas@redhat.com>
>>
>>
>> On Dec 17, 2012, at 3:08 PM, Matthias Wessendorf wrote:
>>
>> > On Mon, Dec 17, 2012 at 9:04 PM, Jay Balunas <jbalunas@redhat.com>
>> > wrote:
>> >> This is similar to what I was thinking as well.
>> >>
>> >> There are two main types of push; native & non-native, but I don't like
>> >> those designations. It is really more like "live" & "background" push,
>> >> referring to the state of the client.
>> >>
>> >> Live push == Application is open, and active on the client. Push msgs
>> >> are routed to the application via more traditional long/short polling,
>> >> websockets, etc...
>> >>
>> >> Background push == Application is closed, and not active on the client.
>> >> Regular live push messages are not possible. The only way to communicate is
>> >> via APN, GC native messaging (sorry web apps - no love).
>> >>
>> >> In an ideal world there would be no difference to the application
>> >> developer using AeroGear API's (client or server). The server-side would
>> >> know what clients are available, and the clients would be listening
>> >> automatically. Sending a message would be agnostic for the server-side.
>> >>
>> >> Unfortunately this can not "fully" be the case as background/native
>> >> messages have limitations on the content, client support, and delivery
>> >> mechanisms.
>> >
>> > one option is, to "push / poll". The client gets a msg on what to
>> > fetch. When back online it performs a "normal" fetch/poll for the data
>> > in question
>>
>> +1 - I've seen that sort of thing as an option for native push - its
>> really just a phone call to tell the app it has an email - go read it :-)
>>
>> >
>> >> So I think the best we can do is setup a "smart" message system that
>> >> gets you pretty close with good fallback api's and checks for what sort of
>> >> messages are possible, or configured.
>> >>
>> >> Make sense, or is this just a big ramble? :-)
>> >>
>> >> -Jay
>> >>
>> >> On Dec 5, 2012, at 2:14 AM, Matthias Wessendorf wrote:
>> >>
>> >>> well,
>> >>>
>> >>> the idea is to have a wrapper/hook for "push notification" (e.g. APN)
>> >>> in the notifier as well:
>> >>> * receiving 'native push' events, when the app is offline (inactive,
>> >>> not watching the tab/window)
>> >>>
>> >>> If an app is offline, you simple can't receive a websocket frame/msg.
>> >>> So push is needed to tell AG that is needs to fetch data for sync etc.
>> >>>
>> >>> -Matthias
>> >>>
>> >>> On Mon, Dec 3, 2012 at 4:51 PM, Burr Sutter <bsutter@redhat.com>
>> >>> wrote:
>> >>>> I am concerned about the words "push" and "notifier" as those can
>> >>>> become confused with real "push notifications" which we will have to have a
>> >>>> client API for in the future.
>> >>>>
>> >>>>
>> >>>> On Dec 3, 2012, at 2:46 AM, Matthias Wessendorf wrote:
>> >>>>
>> >>>>> any further comments?
>> >>>>>
>> >>>>> On Thu, Nov 22, 2012 at 9:51 AM, Matthias Wessendorf
>> >>>>> <matzew@apache.org> wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> yesterday some folks of the team meet, to talk about WebSocket -
>> >>>>>> more
>> >>>>>> generally (HTML5) connectivity.
>> >>>>>>
>> >>>>>> Here is a write-up from the meeting:
>> >>>>>> https://gist.github.com/dd6e3c2da08830776996
>> >>>>>>
>> >>>>>> Feedback and comments are welcome - Please use the comment function
>> >>>>>> on
>> >>>>>> that gist!
>> >>>>>>
>> >>>>>> Cheers!
>> >>>>>> Matthias
>> >>>>>>
>> >>>>>> --
>> >>>>>> Matthias Wessendorf
>> >>>>>>
>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/
>> >>>>>> sessions: http://www.slideshare.net/mwessendorf
>> >>>>>> twitter: http://twitter.com/mwessendorf
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Matthias Wessendorf
>> >>>>>
>> >>>>> blog: http://matthiaswessendorf.wordpress.com/
>> >>>>> sessions: http://www.slideshare.net/mwessendorf
>> >>>>> twitter: http://twitter.com/mwessendorf
>> >>>>> _______________________________________________
>> >>>>> aerogear-dev mailing list
>> >>>>> aerogear-dev@lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev@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
>> >>
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

--
Viele Grüße/Best Regards

Daniel Manzke