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.
Marek