Forgot to mention that I will be out of office Tue-Fri next week. I will reply to your proposal the week after the next.
Marek
On 07/01/2011 07:13 PM, Marek Potociar wrote:
> 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
>>