> 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.
Fine. So when happened that discussion that ended in the decision that we must support pub/sub, broadcast and events? Again, I love to get all that, I just wonder why everbody says this is MISSING in my proposal -- it can only be missing if it would have been REQUIRED. I would wish all experts would frankly tell their expectations clear and loud, instead of discussion "MISSING" stuff in proposal that have been developed on a different expectation. Couldn't Oracle in some way lead this discussions so we all share the same vision before we invest time in writing proposals?
> > 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?
First, you cannot assume that anybody expects that everything found in your paper is a real wish of Oracle. It just could be there as a vision to showcase what brilliant things one *could* do with that.
Second, you told me that your paper actually is not in the state of a proposal already and you just wanted to give a first start. So you cannot assume that I know that your first start actually is naming all requested features.
> 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.
If you can remember, this discussion started because I said that I would love to have a simpler approach. Then Santiago asked me to provide MY counter-proposal in the WIKI. So please Oracle, what way to go now? Talk about YOUR proposal or talk about MY proposal? I do not see big sense in discussing both proposals at the same time. This is confusing. Please do not ask for more proposals if you in fact want to go on with yours first.
> >> 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.
When developing web services today, you can either use Servlets or JAX-RS. The question is: When using which one? And what features to be added to which spec? What is the thin line between Servlet and JAX-RS technology? There are several topics that cover both APIs. Like async. So someone must decide to either put it here or there. In the past weeks I noticed that Oracle seems to have clear vision of that. But that clear vision does not necessarily mean common sense. In details it could be expected different by experts. So it would be good if Oracle would share that vision. For example, Caching was dropped since it is a common http topic, but not a REST topic. So is pub/sub a JAX-RS topic? I don't think so, as pub/sub also is contained in lots of other specs, like MDB/JMS or even Swing Listeners or the rather old Observer class. Maybe it makes sense to have some general pub/sub spec outside of JAX-RS, and make JAX-RS just use it. I do not say that it must be done that way, I just want to say that it is not so clear that all expects accept that Oracle wants to define the actual pub/sub wiring using an explicit JAX-RS API (as contained in your proposal). Can you follow? Just as CDI might replace some EJB stuff in future, maybe you are trying to define JAX-RS API extensions for pub/sub that just will be replaced by some future, generic pub/sub contract also used by MDB/JMS etc. Since you say that all in your proposal is to be understood as "this is what Oracle wants", you obviously have a clear vision that there will never be a generic pub/sub API that JAX-RS can just reuse. If that is the case: Please share your vision with us!
> > 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.
If that is the case, this is ok for me. I just wondered since each I know is using Web Profile.
> >>>>> 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.
So you actually want that JAX-RS users provide their own executor service? I just cannot imagine a JAX-RS user who would have the time to provide a better executor service than the Java SE and Java EE teams. You seem to expect multithreading professionals among your users.