Thx for clarification. It was not just about the server side. They have
also nice wrappers on the clientside. ;)
2012/12/18 Matthias Wessendorf <matzew(a)apache.org>
On Tue, Dec 18, 2012 at 12:46 PM, Daniel Manzke
<daniel.manzke(a)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(a)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(a)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(a)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(a)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(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
>> >>
>> >
>> >
>> >
>> > --
>> > 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
>
>
>
>
> --
> 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