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