[
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.
