One advantage of having Response used on the client and server sides is
that it allows us to consider reusing WAE on both the client and server
sides.
Having ClientResponse & Response (or similar) makes this more awkward.
Would it make sense to consider creating ClientResponse which extends
Response ? That would probably be a good compromise. Response can still
be used on both ends, and cast to ClientResponse on the client side if
needed
Hope it makes some sense
Sergey
On 21/03/12 22:01, Marek Potociar wrote:
>
> On Mar 21, 2012, at 10:24 PM, Sergey Beryozkin wrote:
>
>>
>>>> We should perhaps also think about whether client-side components
>>>> should not go into a separate package so that it is easier to split
>>>> the client and server api into separate jars in the future.
>>>>
>>>
>>> +1
>>
>> How does having client-side components going into a separate package prevents splitting the api into separate jars ?
>
> Perhaps you have misread my comment - it doesn't prevent it, it makes it more possible.
>
> Marek
>
>>
>> Thanks, Sergey
>>
>>
>>
>>>
>>>>> All and all, my proposal probably needs some polishing, but the idea
>>>>> is to have specific contracts at each interception point. I think
>>>>> this is important because we can control exactly what a user can (and
>>>>> more importantly) *cannot* do. With the current API, IMO, there's
>>>>> just way too many weird edge cases you have to code for.
>>>>
>>>> I think the main disadvantage of the current API is that it is not
>>>> mutable, (which is impossible to achieve by extending JAX-RS 1.x
>>>> Request/Response in a sane way...). Another, but solvable,
>>>> disadvantage is that it is not possible to clearly scope filters to a
>>>> particular side.
>>>>
>>>
>>> The scoping is solvable with the current API with a scoping annotation
>>> (to be scanning friendly). But...if you require the annotation, this is
>>> no different, IMO, than having client/server specific interfaces. If you
>>> don't require it, you run the danger of users forgetting to apply the
>>> annotation and problems surfacing at runtime.
>>>
>>> Also:
>>>
>>> A 3rd disadvantage of the current API is that some methods have
>>> different behavior in different contexts.
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>