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