[
https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799829#action_12799829
]
Paul Joseph Davis commented on COUCHDB-583:
-------------------------------------------
Just some quick thoughts reading through the diff:
I'm not a fan of the file containing a list of compressible types. There are
too many types that will just make that configuration hard. Not to mention
exposing an entirely new API endpoint to work with those types is also
needlessly complex.
I'd prefer to see an automatic test trying to compress the first 4K or so of an
attachment and use a heuristic to determine whether it compressed enough to
justify compressing the entire attachment. If that's not doable, the
compressible type system should be integrated into the current configuration
mechanism.
For testing from FireFox it might be best to expose a "attachment is stored in
compressed form" attribute in the _attachments member.
Passing around the <<"Y">> and <<"N">> binaries as a flag for an attachment
being compressed is un-erlangy. true and false atoms would be better.
Test code does not belong in couch_httpd.erl.
Is there something I'm missing on why we need to leak couch_util:gzip*
functions into couch_httpd_db.erl instead of putting all of that logic into
couch_stream.erl?
Is there nothing in mochiweb to handle accept-encoding parsing?
Instead of naming tests test1 -> test17 and comments above each test, just use
a descriptive test name. It might help to group related tests as well so that
tests are easier to find.
Data in the etap tests shouldn't be stored inline when its that big. Create
data files and use the test helpers to reference the filenames and read from
disk.
> storing attachments in compressed form and serving them in compressed form if
> accepted by the client
> ----------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-583
> URL: https://issues.apache.org/jira/browse/COUCHDB-583
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core, HTTP Interface
> Environment: CouchDB trunk
> Reporter: Filipe Manana
> Attachments: couchdb-583-trunk-3rd-try.patch,
> couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch,
> couchdb-583-trunk-6th-try.patch, couchdb-583-trunk-7th-try.patch,
> couchdb-583-trunk-8th-try.patch, couchdb-583-trunk-9th-try.patch,
> jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch
>
>
> This feature allows Couch to gzip compress attachments as they are being
> received and store them in compressed form.
> When a client asks for downloading an attachment (e.g. GET
> somedb/somedoc/attachment.txt), the attachment is sent in compressed form if
> the client's http request has gzip specified as a valid transfer encoding for
> the response (using the http header "Accept-Encoding"). Otherwise couch
> decompresses the attachment before sending it back to the client.
> Attachments are compressed only if their MIME type matches one of those
> listed in a separate config file. Compression level is also configurable in
> the default.ini file.
> This follows Damien's suggestion from 30 November:
> "Perhaps we need a separate user editable ini file to specify compressable or
> non-compressable files (would probably be too big for the regular ini file).
> What do other web servers do?
> Also, a potential optimization is to compress the file while writing to disk,
> and serve the compressed bytes directly to clients that can handle it, and
> decompressed for those that can't. For compressable types, it's a win for
> both disk IO for reads and writes, and CPU on read."
> Patch attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
