[ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799922#action_12799922 ]
Filipe Manana commented on COUCHDB-583: --------------------------------------- Hi Paul, thanks for you're feedback. "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. " Well, this was mostly because I read somewhere in Armstrong's book that binaries are preferred (more efficient) for IO operations (network, disk storage). But I agree, using true / false atoms is more readable. "Is there nothing in mochiweb to handle accept-encoding parsing? " I don't think so, at least in the mochiweb included with couch. It's probably better to move this accept-encoding parsing functions, and the respective test functions, into the mochiweb sources. I'll get back to work and enhance the patch following your remarks. cheers > 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.