On Jun 7, 2011, at 3:30 PM, Bill Burke wrote:
> On 6/7/11 2:19 PM, Markus KARG wrote:
>> Just a few notes I made while reading the samples in the WIKI.
>>
>>
>> * As ResourceUri is not an URI but actually a factory for invocations, it might be better to stick with WebResource, or use a
>>
>> name like Endpoint or InvocationFactory. All those names make clear the "active" aspect of the class, while with ResourceUri
>>
>> everybody might be surprised that it is a factory actually.
>
> A java.net.URI object is sort of a factory as well so I don't see your point. But, I do agree that WebResource is a better name than ResourceUri.
>
> What about Link or Href?
This is going to be a tough one :) A lot of people dislike the term WebResource also. It's going to be hard to please everyone when choosing this term.
>> * The interceptor sample says a possible use of interceptors would be GZIP. As GZIP is a transparent but essential part of
>>
>> HTTP, I doubt that end users will understand that they must user interceptors to add GZIP. I think most would just expect that
>>
>> GZIP is handled transparently by the JAX RS engine or it's transport delegate. I do not think that people would love to see
>>
>> that they must handle GZIP again and again in every application they write. So the GZIP Interceptor should be a mandatory part
>>
>> of any JAX RS implementation.
>
> Interceptors can be used to implement features for frameworks or for applications. I'm sure there are other content encodings out there. I'm sure that the constraints mobile puts on things there will be new compression methods suggested.
>
> That being said, there are different ways to trigger interceptors. Resteasy's GZIP interceptor is automatically bound to client and server request chains. If the Content-Encoding header is set to "gzip" then the interceptor is triggered and it will compress (or uncompress) the request or response entity. We have a different built-in interceptor that can decorate the Content-Encoding header if an annotation or property is set.
>
> I disagree that gzip should be mandatory part of spec. Please, let's not argue about it for 2 weeks.
I also don't think this should be mandatory in the spec.
>> * The complexity of the current annotation based proposal for filters feels a bit overcomplicated. I am a big friend of annotations, aspects and all that, but it just so much simpler to write "Client.from(URL).filter(myFilter).post(entity)" than doing it the proposed way.
>>
>
> I think you're missing the fact that we want to use this interceptor framework on the server side too. The idea here is that you are binding behavior to an annotation. CDI has a similar concept.
That's right. It does feel a bit over-engineered at first, but it makes sense after you put it in practice.
-- Santiago