Santiago Pericas-Geertsen wrote:
> Sergey,
>
> I believe this discussion has hit a roadblock. Putting my spec lead hat for a moment, and given that you feel strongly about this change, I suggest that you file a JIRA issue for further review. Based on the information that you provided, I just don't see enough to warrant a change to the current API at this point.
>
No worries. I'll create JIRA to do with the proposed simplification of Link.
I'm presuming stripping Link off HttpRequest.Builder and making
Invocation implement get()/post() as per Bill's proposal is still on the
map, right ?
Cheers, Sergey
> Let's try to move on to other discussions. Thanks.
>
> -- Santiago
>
> On Jul 8, 2011, at 10:02 AM, Sergey Beryozkin wrote:
>
>> Hi,
>>
>> Bill Burke wrote:
>>> On 7/8/11 8:48 AM, Sergey Beryozkin wrote:
>>>> Bill Burke wrote:
>>>>> On 7/8/11 8:24 AM, Sergey Beryozkin wrote:
>>>>>> Hi Bill,
>>>>>>
>>>>>>> Sergey, client.request(link) is no different than
>>>>>>> client.request(uribuilder) IMO.
>>>>>>>
>>>>>> Link is Configurable and it will have more associated metadata around
>>>>>> URI, describing what this Link is 'about'.
>>>>>>
>>>>>>> You will also want to use Link interface as it current exists, for
>>>>>>> link headers and the hypermedia framework.
>>>>>>>
>>>>>>> so, you could do:
>>>>>>>
>>>>>>> HttpResponse res = client.request(...).get();
>>>>>>>
>>>>>>> res = res.getLinkHeader("edit").request().post();
>>>>>>>
>>>>>>> or, with a hypermedia API like Restfulie:
>>>>>>>
>>>>>>> Customer cust = client.request(...).get();
>>>>>>> client.links(cust).getLink("edit").request().post();
>>>>>>>
>>>>>> That looks nice. One problem I see is that the code like this:
>>>>>>
>>>>>> httpResponse.getLinkHeader("edit").request().post();
>>>>>>
>>>>>> is going to lose Client's features/etc (unless response itself keeps
>>>>>> track of the original Client/Invocation) and IMHO original Client's
>>>>>> features must be in scope unless overridden.
>>>>>>
>>>>> In resteasy we do this very thing. The Link inherits/is-created-from
>>>>> the Client that originated the request.
>>>>>
>>>> Can RestEasy have HttpResponses keeping the original Client
>>>> references/info ? The code where Client start driving the process is
>>>> easy, what about the other example, where HttpResponse starts the process ?
>>>>
>>> Yes. HttpResponses in resteasy know which Client they were created from and initialize links appropriately.
>>>> It's a factory->request, do you see any real difference between passing
>>>> Invocation and factory of invocations around ?
>>>>
>>> Yes, there's a big difference. You pass around Invocation instances so you can implement things like batch processing and the Command Pattern. You pass around Links to provide a reference to a resource. A resource you might invoke separate and different HTTP invocations on. i.e. when you embed it in a document, or within a Link header.
>> I think you are missing the point. Spec or the draft in the wiki (need to check) explicitly talks why passing around invocabale HttpRequests won't be a good idea - do you know why we have HttpRequest & Invocation ? Yet you are nor concerned about explicit link between Link & Invocation
>>
>>
>>>>>> Link with factory methods letting creating Invocable invocations is a
>>>>>> problem, same way HttpRequest with get(), etc, would be.
>>>>>>
>>>>>> Thus, having
>>>>>>
>>>>>> client.request(httpResponse.getLinkHeader("edit")).post();
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> httpResponse.getLinkHeader("edit").request().post();
>>>>>>
>>>>>>
>>>>>> does not look that bad at all IMHO, because:
>>>>>>
>>>>>> - It's easier to push original Client's configuration to the Invocation
>>>>>> being initialized from Link.
>>>>>> - Passing Link around won't have unexpected sideeffects
>>>>>> - It's more obvious that Client is in control
>>>>>>
>>>>> My understanding of the current model was that Link inherits the
>>>>> features/properties of the CLient it was created from.. Those
>>>>> features/properties are overridable by the Link.
>>>>>
>>>>> Why does it need to be obvious the Client is in control? The *LINK* is
>>>>> in control as the Link is allowed to override features/properties it
>>>>> inherited from the Client.
>>>>>
>>>> It does not have to. It just becomes a bit adhoc. Client does one thing,
>>>> Link does something else, Link is effectively a Client.
>>>>
>>> In current model, Link is essentially a Client with a pre-initialized base URI to build requests from. But, Link is also a child of the Client that created it.
>>>> As far as Link is concerned, what we have at the moment is that it:
>>>> 1. captures URI it represents
>>>> 2. acts as a factory of invocations
>>>> 3. capable of modifying URI
>>>>
>>>> 2. is problematic, can you at least accept that Client.request(Link)
>>>> works ?
>>>>
>>> Why would you ever want to do Client.request(Link)? If you have a Link, you can just create the request from there. You're creating problems that just don't exist.
>> Bill, please stop assuming I'm just poking around and looking for weak spots in API. That is not true. I'm working in this group now and I'd like to contribute to what I see would be a cleaner API, and I'd also like to keep CXF interests in mind, like many of us want to do with their own implementations.
>>
>> I'd like API be embraced by users *enthusiastically*. +1 to cool and useful features. But I'd like API being consistent. A clear separation between HttpRequest & Invocation for the purpose of neutral handlers not being able to mess things up but having an explicit Link to Invocation link is obviously inconsistent if we are seriously talking about Link being idempotent references which can be passed around.
>>
>> IMHO Link is overloaded. I don't think it will be the end of the world if Link factory methods will stay.
>> But I'd like to be able to recommend CXF users to use
>>
>> Client.request(Link).
>>
>> Why ? Because it would give conscious users an option to keep the Invocation initialization centralized, etc
>>
>> Sergey
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> http://sberyozkin.blogspot.com
>> Talend - http://www.talend.com
>>
>>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com