[
https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783498#action_12783498
]
Paul Joseph Davis commented on COUCHDB-583:
-------------------------------------------
As Adam says, discussion is about as far as things have gone. It would indeed
be a very good fit for CouchDB.
The last remaining issue though is how it does streaming of entity bodies.
Right now it expects CouchDB to be able to have a call back mechanism which is
a huge impedance mismatch for the control flow of iterating views.
I've been working on a python port of webmachine the last couple days and as
part I've been trying to think how to patch webmachine to return a
write-callable that could be passed to our streaming output. I haven't gone
through the lower end bits of where its handling streaming output, but at the
moment it looks like a fairly big patch to the body handling facilities in
webmachine. If I get time I'll try and code a patch that doesn't affect the
status quo, and then we can start to seriously think about tacking webmachine
onto CouchDB.
> adding ?compression=(gzip|deflate) optional parameter to the attachment
> download API
> ------------------------------------------------------------------------------------
>
> Key: COUCHDB-583
> URL: https://issues.apache.org/jira/browse/COUCHDB-583
> Project: CouchDB
> Issue Type: New Feature
> Components: HTTP Interface
> Environment: CouchDB trunk revision 885240
> Reporter: Filipe Manana
> Attachments: jira-couchdb-583-1st-try-trunk.patch,
> jira-couchdb-583-2nd-try-trunk.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The following new feature is added in the patch following this ticket
> creation.
> A new optional http query parameter "compression" is added to the attachments
> API.
> This parameter can have one of the values: "gzip" or "deflate".
> When asking for an attachment (GET http request), if the query parameter
> "compression" is found, CouchDB will send the attachment compressed to the
> client (and sets the header Content-Encoding with gzip or deflate).
> Further, it adds a new config option "treshold_for_chunking_comp_responses"
> (httpd section) that specifies an attachment length threshold. If an
> attachment has a length >= than this threshold, the http response will be
> chunked (besides compressed).
> Note that using non chunked compressed body responses requires storing all
> the compressed blocks in memory and then sending each one to the client. This
> is a necessary "evil", as we only know the length of the compressed body
> after compressing all the body, and we need to set the "Content-Length"
> header for non chunked responses. By sending chunked responses, we can send
> each compressed block immediately, without accumulating all of them in memory.
> Examples:
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=gzip
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=deflate
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt # attachment will
> not be compressed
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=rar #
> will give a 500 error code
> Etap test case included.
> Feedback would be very welcome.
> cheers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
