On 30/03/12 16:40, Marek Potociar wrote:
>
> On Mar 30, 2012, at 12:34 PM, Bill Burke wrote:
>
>>
>>
>> On 3/30/12 5:25 AM, Sergey Beryozkin wrote:
>>>> Another option is to extend the ClientResponse from the Response. This
>>>> makes the Response.Status/StatusType reuse more natural, but client
>>>> side suffers from the "weird method" issues that we identified in the
>>>> common Request/Response model. IOW, one of the main issues why we
>>>> started this exercise has not gone away... Also, reusing WAE as a
>>>> common exception super-type is problematic due to the need to downcast
>>>> the Response in the WAE on the client side or do some other similar
>>>> tricks.
>>>
>>> I thought the issue was that some of the current Response methods
>>> introduced in 2.0 did not quite make sense on the server side ?
>>> Response in 1.1 has 3 methods, getStatus(), getEntity()& getMetadata(),
>>> all of these methods have the complete sense on both ends, they are just
>>> not client-friendly.
>>>
>>
>> When you think about it, even with the current API "getMetadata()" doesn't fit either and would never be used.
>>
>> For a ClientResponse extends Response: I agree that all three methods sort-of work.
>>
>
> See my other reply where I try to argue otherwise.
>
>>
>>>>
>>>> The last option is to keep the common Response mostly as is and
>>>> rollback only the changes in the Request. The advantage is that reuse
>>>> of the member types is natural on both, client and server. The
>>>> disadvantage is that the "weird method" syndrome is visible again on
>>>> both, client and server. The good thing would be that with new
>>>> filtering infrastructure not based on the Request/Response types, the
>>>> problem would mainly be visible in some client scenarios. Also reusing
>>>> WAE as the common super-type becomes more possible s well as
>>>> ResponseBuilder.
>>>>
>>>> I wish Status& StatusType were not defined inside the core.Response.
>>>> Things would have been much more simpler. All in all, seems to me we
>>>> should either do a complete radical cut between the client and the
>>>> server or keep the common Response. To me the middle option is just
>>>> not appealing enough. It looks more like a collection of the problems
>>>> from both worlds rather than a good solution.
>>>>
>>>> Thoughts?
>>>
>>> I like the following options:
>>> - ClientResponse is standalone and optimized for the client to retrieve
>>> the data and headers. However in this case we should not be too
>>> concerned about WAE or Response (via WAE) 'leaked' to the client runtime
>>> because as I said above there was nothing in Response signature that the
>>> client were not capable of working with. We can think about (internal)
>>> conversions/adaptation between Response& ClientResponse if the 'leak'
>>> is not desired but I'd not worry about it a lot.
>>>
>>> - ClientResponse extending Response
>>>
>>> This is may not look like the good design decision but it makes a
>>> complete sense in terms of "ClientResponse is Response *optimized* for
>>> the client to process the server response". That will also make the idea
>>> of reusing child server exceptions with the root WAE practical.
>>>
>>
>> I agree with Sergey. ResponseBuilder can also be re-used when you want to abort in a client-side filter (i.e. the cache example).
>
> Again, see my other reply. I tried this, feels weird when used. Feels like you are mixing server and client side components which in the end will somehow automagically work. Interestingly, with a single common Response, the things don't feel so confusing.
>
Interesting. Retaining a common Response might also be an option,
however I'd then propose move some of the methods to do with buffering,
etc, to some client side utility or drop them, would you consider it ?,
and also define what the other read methods should do on the server side
Sergey
> Marek
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com