Off-topic: would be really cool to add the Code By Convention stuff we
talked at the very beginning of the spec.
On 4/30/12 1:48 PM, Martin Matula wrote:
> OK, so basically no changes from the status quo then. Just clarifying a few things in the spec/javadoc.
> And discussing the addition of annotations on the client side which I guess can be done after EDR3.
> Martin
>
> On Apr 30, 2012, at 5:27 PM, Bill Burke wrote:
>
>>
>>
>> On 4/30/12 11:05 AM, Martin Matula wrote:
>>> Hi Bill,
>>>
>>> On 4/30/12 4:30 PM, Bill Burke wrote:
>>>>> 2) readEntity() should make an implicit call to bufferEntity() before it
>>>>> does anything. This is just for filters! Not for reading in the resource
>>>>> method or the client.
>>>>
>>>> Just a thought..Maybe it shouldn't be implicit? Maybe the filter is
>>>> reading the entity, then replacing it with writeEntity(), so a buffer
>>>> is overkill? Or maybe its just better to protect the filter developer
>>>> from himself? I don't know...
>>>
>>> OK, not implicitly buffering may provide more flexibility. On the other
>>> hand one poorly written filter can break everybody else. Not sure what's
>>> better. I don't have a strong opinion on this one.
>>>
>>>>
>>>>> 3) maybe - remove get/setEntityStream() from filters (could not find a
>>>>> use-case that could not be covered by interceptors or a combination of
>>>>> an interceptor and a filter that triggers the interception by calling
>>>>> bufferEntity()). Or maybe we want to keep it to be safe. Which leaves us
>>>>> with just the two things above.
>>>>>
>>>>> Here is the rationale:
>>>>>
>>>>> - on the receiving end, you want "decoding" interceptors to work based
>>>>> on the headers, not based on the annotation - i.e. if the entity in the
>>>>> incoming message is zipped, it is not the resource method that tells me
>>>>> it is, it is the sender who should tell me - by the way of the headers.
>>>>> So, typically no annotations processing should be needed to make the
>>>>> stream usable for other consumers. At least I think I would never add a
>>>>> feature that would not have this kind of characteristics.
>>>>>
>>>>
>>>> hashes or signatures?
>>>
>>> Shouldn't the hashes/signatures be verified based on headers then? I.e.
>>> if the sender sends a hash/signature, don't you always want to verify?
>>
>> Verification is expensive. Because you have to:
>>
>> a) recreate the hash
>> b) encrypt the hash
>> c) compare
>>
>> So, I would say, no, you don't always want to verify.
>>
>>> And only use the annotation for enforcement? That way your verification
>>> interceptor can be global and the enforcement would be name-bound. And
>>> things would work. Or do you need to read something from the annotations
>>> which is essential for the signature/hash computation?
>>>
>>
>> Annotation could have the hashing algorithm specified. But usually the information is contained in a header somewhere.
>>
>>> Otherwise I don't know how to implement it cleanly - I guess you would
>>> have to buffer headers (if you want to buffer the original stream) as
>>> well, since after my gzip interceptor removes the encoding header and
>>> somebody later reads the original stream from the buffer, my gzip
>>> interceptor will no longer know it has to decode - unless it gets the
>>> buffered original headers as well, no? The "mark" in the property bag
>>> would not be enough in this case, as the interceptor does not know when
>>> it works with the original stream as opposed to a new stream created as
>>> a result of writeEntity(). Seems to make things too complicated, no?
>>>
>>
>> Why would a gzip interceptor remove the encoding header?
>>
>>>> * If you call writeEntity() what should happen to headers? For
>>>> example, if the original wire bytes are gzip encoded and you call
>>>> writeEntity() what happens to the Content-Encoding header? In this
>>>> case, maybe we writeEntity() should have an additional headers parameter?
>>>>
>>>> public<T> void writeEntity(
>>>> final MultivalueMap<String, Object> newHeaders,
>>>> final GenericType<T> genericType,
>>>> final Annotation annotations[],
>>>> final MediaType mediaType,
>>>> final T entity);
>>>
>>> What would you pass to the header parameter?
>>> writeEntity triggers interceptors, based on the current headers, the
>>> gzip interceptor would either kick in or not, no?
>>>
>>
>> Oh yeah, I guess it would. Good point.
>>
>>> One more thing - should annotations[] be added to the client API
>>> somewhere (e.g. to the methods that work with entity or to the Entity
>>> class) to make name-bound interceptors reusable on the client side?
>>
>> Yes. And it would also work well with our proxy framework :)
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com