Jan,
At least one more person outside of the EG commented on this sample. I've just incorporated this simple change to the spec.
-- Santiago
On Oct 29, 2012, at 10:43 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
> Hi Santiago,
>
> On Oct 29, 2012, at 3:28 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>
>>
>> On Oct 29, 2012, at 3:30 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>
>>>
>>> On Oct 27, 2012, at 4:41 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>>>
>>>> The examples in the spec illustrate JAX-RS APIs not any particular feature implemented with these APIs. So I think we should keep the examples simplistic in the spec. The features you're talking about will be most likely provided by more skilled developers anyway.
>>>
>>> After mulling this over, I disagree. The examples also bother to show finishing the gzip OS and restoring the original OS.
>>
>> It's certainly not the intent of the spec samples to be 100% precise; conciseness is a more important goal IMO. However, it wouldn't affect conciseness much to write:
>>
>> @Override
>> Object aroundReadFrom(ReaderInterceptorContext ctx) ... {
>> if (isGzipped(ctx)) {
>> InputStream old = ctx.getInputStream();
>> ctx.setInputStream(new GZIPInputStream(old));
>> try {
>> return ctx.proceed();
>> } finally {
>> ctx.setInputStream(old);
>> }
>> } else {
>> return ctx.proceed();
>> }
>> }
>>
>> @Override
>> void aroundWriteTo(WriterInterceptorContext ctx) ... {
>> OutputStream old = ctx.getOutputStream();
>> GZIPOutputStream gzipOutputStream = new GZIPOutputStream(old);
>> ctx.setOutputStream(gzipOutputStream);
>> updateHeaders(ctx);
>> try {
>> ctx.proceed();
>> } finally {
>> gzipOutputStream.finish();
>> ctx.setOutputStream(old);
>> }
>> }
>>
>> Could we move on from this discussion with this simple change?
>
> I wasn't planning to hammer on this further, but yeah - that is really all I had in mind when I initially wrote there should be a little comment noting that headers likely need an update. Your addition does that perfectly.
>
> And sorry - but my overall bias is always to provide guidance to help people make less mess out of REST/HTTP and not more. IOW, I see more in JAX-RS than 'just' a programming tool. It influences people's understanding of REST/HTTP substantially.
>
> Jan
>
>>
>> -- Santiago
>>
>