couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: Improving MIME attachment processing in CouchDb
Date Tue, 03 Dec 2013 09:08:16 GMT
Hey Nick,


Sounds great to me. I'll look for somebody else to review your PR -- thanks!

Re 5, improved mime parsing speed, let's get a branch or patch up for that
ASAP.

Here's a good place to discuss, but for proposed specific changes a JIRA
ticket is likely better.

A+
Dave




On 2 December 2013 17:15, Nick North <north.n@gmail.com> wrote:

> Following some earlier email discussions, I'm interested in contributing to
> CouchDb to improve handling of MIME attachments, and have some questions
> about the philosophy of the current code, to make sure that my changes are
> in the right spirit. Specifically the things I'd like to improve are:
>
>
>    1. Allow POSTing of MIME attachments with a document. There's already a
> pull
>    request <https://github.com/apache/couchdb/pull/91> in for this.
>    2. Allow chunked MIME requests, in order to:
>    3. Remove the need for attachment lengths to be supplied in the JSON
>    document.
>    4. Remove the requirement that attachments are in the same order in the
>    JSON document as they are in the MIME body.
>    5. Improve parsing speed for MIME bodies. I have some small changes that
>    speed this up by a factor of about 4 in rough tests and could submit
> them
>    separately if that is useful.
>
> Having looked at the code, my questions are to do with chunked requests,
> and whether it would be appropriate to use the existing
> couch_httpd:recv_chunked function or not. Is this the right forum for
> detailed questions in this area? If not, where is the best place to raise
> them? I'm happy to get stuck in to writing the Erlang to make the changes
> above but want to make sure that I work in a way that's in tune with the
> rest of CouchDb, so am keen to get advice from the experts.
>
> Thanks for your help,
>
> Nick
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message