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