Hi Sergey,
I am looking forward to your proposal.
FWIW, I am not particularly happy myself about the get().invoke(), but right now after all the cycles we went through
and all the API versions we have reviewed already, I consider this as a reasonable trade-off between various
requirements on the API (API complexity, batch processing support etc.).
Marek
On 07/01/2011 05:51 PM, Sergey Beryozkin wrote:
> Hi Marek,
>
> I now understand what exactly I'd like to propose and which can qualify as an evolutionary as opposed to 'revolutionary'
> proposal.
>
> What I realized is that when I talk about "Client" I actually refer to what is now called Link in the existing draft.
> When you refer to "Link" you are actually referring to what I consider being a "Client". When you refer to "Client" you
> actually refer to what I consider being "ClientFactory" but your clarification about ClientFactory being an entry point
> into Client API makes sense too.
>
> Given the above I'm going to propose what I'd consider a non-major update.
>
> More comments inline
>
>>
>>>>> We do it in CXF, the indications are users do use it, and I haven't had yet anyone complaining about the complexity of
>>>>> CXF JAX-RS client API or being limited (except that we don't do async support yet)
>>>> I'm afraid that "CXF JAX-RS client API" is an oxymoron :) It's either CXF or JAX-RS. Anyway, let's stick to the
>>>> technical discussion rather than arguing about what Jersey/CXF/Resteasy client API users complain or not complain
>>>> about.
>>> Marek - you misunderstand what "CXF JAX-RS" is and in the community where people are aware of multiple implementations
>>> it's a well-known fact that "CXF JAX-RS" is a shortcut for referring to the JAX-RS implementation in Apache CXF project.
>>> Besides I was not referring to it in order to argue - it was part of my case for attempting to refer to the fact that
>>> simplicity can be achieved without extra complexity, no more than that, thus I don't think your comment above is fare.
>>
>> What I meant is that right now, there is *no* JAX-RS client API, so CXF cannot have JAX-RS client API implemented. I
>> have missed that you are using "CXF JAX-RS" as a collocation. I am sorry, I did not want to sound mean. My main point
>> here was that using community feedback as an argument makes sense if there *is* a feedback.
>
> np, it was my fault I mentioned CXF which caused some confusion :-)
>
>>>
>>> HTTPRequest & Invocation are OK. Making Invocation a central piece if API is the main problem IMHO.
>>
>> Can you please explain the problem you see?
>>
>
> myLink.get().invoke()
>
> is not right IMHO. It 'loses' the 'message' of what simple HTTP-centric programming is about. Chain needs to finish with
> HTTP verb action. However I also see the benefit of having Invocation.invoke on its own but I'm for making an
> Invocation-centric programming an optional feature as opposed to a core feature of API,
>
> Will send the proposal next week
>
> Thanks, Sergey
>