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