couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson (JIRA)" <>
Subject [jira] Commented: (COUCHDB-583) storing attachments in compressed form and serving them in compressed form if accepted by the client
Date Fri, 29 Jan 2010 03:49:34 GMT


Chris Anderson commented on COUCHDB-583:

I think this patch is pretty much ready. In IRC I asked about renaming identity_len and len
to raw_len and stored_len to make it more clear what they are referring to.

I've looked through the disk and storage parts of the patch and they seem solid and ready
to go. 

I've just noticed something else:

The changes in mochiweb for accepted_encodings. Did this patch go back to mochi yet?

There is an Erlang Mimeparse library that should handle the q values etc, and it's heavily
tested. Our JavaScript side uses a JS port of the original Mimeparse library. I think it'd
be better to patch Mochiweb to use Mimeparse than to write a new one that's not under they
scrutiny the original Mimeparse is.

Is there a reason not to use Mimeparse here? Can I persuade you to make that change? Maybe
there's a way we can use Mimeparse to avoid having to patch Mochiweb at all?

Thanks for working so hard at this. You've picked probably one of the more challenging features
in all of Couch.

> storing attachments in compressed form and serving them in compressed form if accepted
by the client
> ----------------------------------------------------------------------------------------------------
>                 Key: COUCHDB-583
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: Database Core, HTTP Interface
>         Environment: CouchDB trunk
>            Reporter: Filipe Manana
>         Attachments: couchdb-583-trunk-10th-try.patch, couchdb-583-trunk-11th-try.patch,
couchdb-583-trunk-12th-try.patch, couchdb-583-trunk-13th-try.patch, couchdb-583-trunk-14th-try-git.patch,
couchdb-583-trunk-15th-try-git.patch, couchdb-583-trunk-16th-try-git.patch, 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
> Patch attached.

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

View raw message