On 08/02/2011 08:13 PM, Markus KARG wrote:
>>>>> Pub/Sub support is currently not on our agenda
>>>> I disagree.
>>>
>>> Maybe I am temporarily blind, but where in our mission charter is
>> pub/sub mentioned?
>>
>> Forget pub/sub. Wrong term. My bad. Full stop. As for resuming multiple
>> requests based on a single async event, I really
>> don't see any issue wrt. our charter. We state we will provide async
>> support. We don't specify the details of the
>> support in the charter. Just because a feature is not explicitly listed
>> in the charter doesn't mean the feature is not
>> currently on our agenda.
>
> So where is the document that says what features are to be solved and which are not? I mean, how should I write a proposal if some people expect more than told in the charter, while others do not? I like pub/sub and broadcast, but I need to know *before* posting a proposal, not afterwards.
You can put in a proposal any features that you find important and/or useful. We have the EG list to discuss the final
scope. That's the way we typically do it.
>
>>>>> and I actually doubt it is RESTful.
>>>>
>>>> Unless you provide some additional reasoning, the argument is kind
>> of
>>>> cheap :)
>>>
>>> Yes it is cheap, but we do JAX-RS not JAX-OtherCoolStuff, do we? ;-)
>>
>> You don't seem to understand. My point is that it's easy to claim that
>> something is not RESTful. Proving it is the
>> harder part.
>
> As you like to get the feature, can YOU proof that it IS RESTful? REST is a copy of the way the web worked in the year 2000 -- there was no ATOM or COMET back then, so I doubt RTF actually had pub/sub in mind when first coining the term "REST". Anyways, I don't care. If Oracle wants that feature (and I like that feature) then Oracle just should clearly say. I have no problem with it, I just want to know before a discussion starts what the target of the discussion shall be.
I proposed the feature of being able to resume multiple requests with a single event on behalf of Oracle. How more clear
you want me to be about the fact that Oracle wants the feature? That said, it is still just an initial proposal, note a
done deal. I am open to discuss it. If experts bring up valid reasons for not including the feature in the API, we would
certainly consider those. FWIW, I already noted some reasons pointed out by Bill Burke.
>
>>> In fact, I often had wished that there would be some kind of merger
>> of Servlet API and JAX-RS as in fact a lot of applications are not
>> quite RESTful but just simpler to do with JAX-RS than with Servlet API.
>> So I do understand that pub/sub is an interesting thing to cover (and
>> in fact I would love to have http based pub/sub support in our
>> application to get rid of proprietary JMS streams), but I actually do
>> not think that this is really part of our current mission statement.
>> Pub/Sub in future will be done by lots of applications using WebSockets
>> for example, and those are explicitly excluded. So what sense would it
>> make to provide pub/sub, if we do not provide WebSockets support?
>>
>> No-one is ruling out proprietary support for comet or websockets. We
>> would however not put it into the API, since this
>> area needs more experimenting.
>
> The problem is that obviously Oracle seems to have some clear vision of the border line between what goes into Servlet and what goes into JAX-RS, but to others (like me) that is not so clear: Pub/Sub is -in my understanding- not covered by the topic "REST" (see above), so it is not necessarily part of JAX-RS. On the other hand, Servlets already come with support for that. So if Oracle has such a clear distinction of what has to go into which spec, you maybe should post this clear vision before asking for comments. So we all understand what you are aiming.
I am not sure I follow.
>
>>>> Not all JAX-RS users run their apps in a full JavaEE environment. I
>>>> would prefer we don't try to introduce features that
>>>> conditionally work only in some environments.
>>>
>>> It was just one possible solution to the mentioned problem. There can
>> be other solutions which will work in Java SE. BTW, in times of
>> embedded GlassFish and Web Profiles, why should one actually use JAX-RS
>> in a non EE environment?
>>
>> I don't know. Maybe because one is an OSGi or Spring purist or wants to
>> run the service in Google AppEngine or ...
>
> Don't you think that we should concentrate on those things actually being developed by JCP? I mean, do you really trying to define an API that will work with *anything*? And, do you really think that even a OSGi or Spring addict will not have the need for a container to drive JAX-RS, and which container these days will not support the web profile? Anyways, let's stop this. Obviously, you have a clear vision what you like to get which I cannot guess and you don't like to share in one single big picture, so it makes no sense to go on with this sub-thread.
I am convinced that it makes *a lot of* sense to keep JAX-RS usable outside JavaEE. In Jersey we have many users not
sunning Jersey in a JavaEE container. We certainly don't want to limit their options.
>
>>>>> Seems you more care for Pub/Sub than for async. ;-)
>>>>
>>>> Actually, I do care for both. A feature of resuming multiple
>> responses
>>>> based on a single event seems interesting enough
>>>> to explore it in more detail.
>>>
>>> Yes certainly it is. But it shouldn't be used as the silver bullet
>> that kills simplicity for all others that do not need pub/sub but just
>> want to get rid of long running process delay or lots of blocked
>> container threads.
>>
>> What makes you think that we would kill the simplicity because of
>> supporting this additional feature?
>
> If you can remember the start of this thread: I complained about your proposal being too complex for use cases besides pub/sub and broadcast. Anyways, as Bill already told, it seems you actually do not mean simply async, but in fact you mean events. So then the complexity is definitively needed (at least in part) and we can stop here.
>
>>>>> What scenario do you have in mind that is not possible with my
>>>> proposal?
>>>>
>>>> It's not a question of being possible or not. If we just provide a
>> way
>>>> of resuming a single request, then everything is
>>>> possible. It does not however mean that it would be easy at the same
>>>> time. I am shooting for making it easy.
>>>
>>> Actually I thought my proposal IS more easy than yours...?!
>>
>> Seems to me that you had to provide lot of additional details to
>> explain how it's supposed to work in this forum. There
>> are hidden details that make it less understandable IMO.
>
> In fact I just had to provide a few code lines, just like you. And there are no hidden details. You just are fixed on events while I was fixed on pure async. There is no magic in my proposal, but I saw a lot in yours. Can you explain exactly what hidden details you mean or what you do not understand in my proposal actually?
I already did mention one - implicit connection between Future return value and the proposed JAX-RS executor service.
Marek