[jira] Issue Comment Edited: (WINK-152) Automatic content encoding

["Bryant Luk (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WINK-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753632#action_12753632 ] 

Bryant Luk edited comment on WINK-152 at 9/10/09 7:19 AM:
----------------------------------------------------------

The way that you've described the fine grained encoding seems simple enough but I wanted to sketch out some more of it:

In the interface (say "ContentEncoder"), 

{code}
public class GZipEncoder implements ContentEncoder {
    
   private GZIPOutputStream gzipOutputStream;

   public GZipEncoder() {
      /* no arg constructor required */
   }

   public OutputStream getOutputStream(OutputStream original, MultivaluedMap<String, String> responseHeaders) {
       gzipOutputStream = new GZIPOutputStream(original);
       // add Content-Encoding and Vary header
       return gzipOutputStream;
   }

   public boolean isAcceptable(HttpHeaders requestHeaders) {
       // if this should be used. based on Accept-Encoding or other HTTP headers
    }

   public void finish() {
        gzipOutputStream.finish();
   }
}
{code}

I don't know if this is what you meant but I think it's good to have a default implementation that will "do the right thing" so you don't have to specify a class (i.e. as an application developer, I want to just encode the thing).

{code}
@EncodeContent
public Response getSomething() 
{code}

would encode it in any acceptable encoding that is supported by default (gzip, deflate, ....)

{code}
@EncodeContent(Gzipper.class, Deflater.class)
public Response 
{code}

would only encode in gzip or deflate (only encoding once and first in the list, "wins";  if multiple encoders need to be used, then the first encoder should directly call the other encoders itself).

=====

As far as a global encoding, would you be opposed to having a servlet filter that can be optionally added?  It may suffice for doing "global" automatic encoding/decoding.  That way less code has to be changed in the regular paths.  I originally wanted to have an option in cases where the application developer wants to write directly to the stream but it is probably better to give an all or nothing.

      was (Author: bluk):
    The way that you've described the fine grained encoding seems simple enough but I wanted to sketch out some more of it:

In the interface (say "ContentEncoder"), 

{code}
public class GZipEncoder implements ContentEncoder {
    
   private GZIPOutputStream gzipOutputStream;

   public GZipEncoder() {
      /* no arg constructor required */
   }

   public OutputStream getOutputStream(OutputStream original, MultivaluedMap<String, String> responseHeaders) {
       // check headers, if not acceptable return the original
       gzipOutputStream = new GZIPOutputStream(original);
       // add Content-Encoding and Vary header
       return gzipOutputStream;
   }

   public boolean isAcceptable(HttpHeaders requestHeaders) {
       // if this should be used. based on Accept-Encoding or other HTTP headers
    }

   public void finish() {
        gzipOutputStream.finish();
   }
}
{code}

I don't know if this is what you meant but I think it's good to have a default implementation that will "do the right thing" so you don't have to specify a class (i.e. as an application developer, I want to just encode the thing).

{code}
@EncodeContent
public Response getSomething() 
{code}

would encode it in any acceptable encoding that is supported by default (gzip, deflate, ....)

{code}
@EncodeContent(Gzipper.class, Deflater.class)
public Response 
{code}

would only encode in gzip or deflate (only encoding once and first in the list, "wins";  if multiple encoders need to be used, then the first encoder should directly call the other encoders itself).

=====

As far as a global encoding, would you be opposed to having a servlet filter that can be optionally added?  It may suffice for doing "global" automatic encoding/decoding.  That way less code has to be changed in the regular paths.  I originally wanted to have an option in cases where the application developer wants to write directly to the stream but it is probably better to give an all or nothing.
  
> Automatic content encoding
> --------------------------
>
>                 Key: WINK-152
>                 URL: https://issues.apache.org/jira/browse/WINK-152
>             Project: Wink
>          Issue Type: New Feature
>          Components: Common
>            Reporter: Bryant Luk
>            Assignee: Bryant Luk
>         Attachments: WINK-152.patch
>
>
> It would be neat to have an automatic content encoding feature.  In particular, gzipping content for clients that support it (via Accept-Encoding header) can improve response times.
> A property for automatically compressing/decompressing content available in Wink or an annotation specified on a resource or resource method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.