Bill,
I know what it is good for, but my declared intention was to add Pub/Sub,
Broadcast, Events ontop later actually. Events are just a special case of
pub/sub with a single subscriber. I thought that it was mentioned clearly in
the article that the idea is to just define the asynchronous base technology
and solve everything ontop in a later proposal. I never said the proposal is
providing all features wanted in this context. In fact I have not even
thought about the next step but just wanted to make clear that it should be
much simpler for the programmer to declare his needs, as this discussion
started with my complaint that the original proposal is looking far too
complex, remember? My hope was that it there might be a simple way and by
posting the alternative proposal other experts might see what I want to head
for and can contribute ideas how pub/sub, broadcast and events can be (maybe
easily) added. But you are right, if you hoped to get a perfect ready-to-use
proposal for all async topics, then yes, this is not contained in my
proposal.
Regards
Markus
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 1. August 2011 13:53
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Simplified Async Proposal
>
> I'm not sure you understand what Async HTTP is for. It is used for
> Server-side push. In other words, the client does a long poll to the
> server waiting for the server to be ready to send it an event. i.e. a
> stock quote update, or a chat message. You want to detach the
> HttpResponse from a thread so that one server-side thread can dispatch
> to usually more than one HttpResponse.
>
> Your proposal doesn't address this use case at all, IMO.
>
> IMO, Async HTTP is way overhyped and we should only offer minimal
> support for it. It is solely a performance feature that became an
> issue, IMO, because of the older Linux kernels where threads were so
> heavyweight. Now this isn't so much an issue with modern kernels and
> hardware. Other languages, i.e. Erlang, scale better as they
> automatically suspend threads and do their own internal context
> switching.
>
>
> We want first and foremost to provide the ability to detach a response
> from a thread and a mechanism to handle the response asynchronously
> *however* the application code.
>
> Alternatively, we could provide a lightweight message bus, i.e. via the
> Atmosphere apis, but, IMO, this is a bonus, not a requirement.
>
> On 7/30/11 5:16 AM, Markus KARG wrote:
> > I was asked to put my simplified async proposal in the wiki so
> experts
> > can better understand and discuss it.
> >
> > So here it is:
> > http://java.net/projects/jax-rs-spec/pages/SimplifiedAsyncSupport
> >
> > Please post comments in this mailing list. :-)
> >
> > To sum up a few points from previous discussions:
> >
> > * Broadcast and Pub/Sub is not part of the proposal, but should be
> > simple to implement ontop.
> >
> > * No more need for polling or suspending, due to an updated attempt
> > (using Callable instead of Future).
> >
> > * Should be the most simple to learn and apply for programmers, as
> there
> > is either nothing to learn (Callable) or just one annotation to add
> > (@Async).
> >
> > * Should be rather easy to implement for JAX-RS implementation
> vendors,
> > but opens a lot of possibilities for them like applying work stealing
> etc).
> >
> > -Markus
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com