couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: [jira] Commented: (COUCHDB-583) storing attachments in compressed form and serving them in compressed form if accepted by the client
Date Wed, 27 Jan 2010 15:37:24 GMT
s/vbuilds/vpath builds/

I obviously need another cup...

On Wed, Jan 27, 2010 at 10:34 AM, Paul Joseph Davis (JIRA)
<jira@apache.org> wrote:
>
>    [ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805539#action_12805539
]
>
> Paul Joseph Davis commented on COUCHDB-583:
> -------------------------------------------
>
> @Filipe,
>
> Actually you want to use test_util:src_file(Path).
>
> The way to double check that you have everything down pat is to run:
>
>     $ make distcheck
>
> And that'll go through the full set of checks to see if your code is distribution ready.
>
> For a brief explanation, autotools has a feature called vbuilds that allows people to
expand the source on a read-only mount, and then build to a writable location. So you have
two directories (srcdir and builddir) and srcdir must be treated as read-only. This means
that if you want to touch a file that was part of the release tarball (not all files in SVN
are part of this, touching files during a build that aren't part of a release also causes
errors) you use srcdir. If the file of interest is a file that's being written to, or was
generated as part of a make rule, then it's in builddir.
>
> The relevant autotools docs are:
>
> http://www.gnu.org/software/hello/manual/automake/VPATH-Builds.html
> http://www.gnu.org/software/make/manual/html_node/General-Search.html
> http://www.gnu.org/software/make/manual/html_node/Commands_002fSearch.html#Commands_002fSearch
>
> Those all go over the weirdness to some extent. I'm remembering another helpful page
vaguely but can't figure out what it was.
>
>> 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-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-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.
>
>

Mime
View raw message