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: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Date Fri, 27 Feb 2009 00:59:24 GMT
On Thu, Feb 26, 2009 at 7:58 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 7:37 PM, Jeff Hinrichs - DM&T
> <dundeemt@gmail.com> wrote:
>> On Thu, Feb 26, 2009 at 9:47 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>>> On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T
>>> <dundeemt@gmail.com> wrote:
>>>> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <jan@apache.org> wrote:
>>>>>
>>>>> On 26 Feb 2009, at 09:03, Brian Candler wrote:
>>>>>
>>>>>> On Wed, Feb 25, 2009 at 07:07:11AM -0600, Jeff Hinrichs - DM&T
wrote:
>>>>>>>>
>>>>>>>> CouchDB dodges this at present, since you can't download
a document
>>>>>>>> together
>>>>>>>> with its attachments.
>>>>>>>
>>>>>>> what about ?attachments=true  or am I misunderstanding you?
>>>>>>
>>>>>> This is new to me - such feature doesn't seem to be mentioned at
>>>>>> http://wiki.apache.org/couchdb/HTTP_Document_API, where it says:
>>>>>>
>>>>>> "When retrieving documents, the attachment's actual data is not included,
>>>>>> only the metadata. The actual data has to be fetched separately,
using a
>>>>>> special URI."
>>>>>>
>>>>>> However I do see "attachments=true" in couch_rep.erl. Is this something
>>>>>> internal/private for replication?
>>>>>
>>>>> This is an omission in the documentation. I added it to the wiki now
with
>>>>> a note that you should not use it :) I think the plan forward is to add
an
>>>>> API
>>>>> where documents and attachments can be transferred in a single HTTP
>>>>> request using a multipart mime request. This will speed up replication,
>>>> Not immediately apparent that this is true, only if mime encode/decode
>>>> is faster than json encode/decode
>>>>
>>>
>>> The major speed up factors when doing this in multipart mime are:
>>>
>>> 1. Streaming bytes from and to disk for attachments.
>>> 2. No Base64 round trip
>>> 3. No base64 means less data transferred
>>>
>>> Seems like I'm missing another one, but those are the biggies.
>>
>> I knew there had to be more to it than what I was understanding.   Any
>> chance you could point me to a reference for multipart mime requests?
>> I ran a goog this morning but ended up with lots of email oriented
>> hits.
>>
>>> HTH,
>>> Paul Davis
>>>
>>>>> fix handling replication with large attachments and makes it possible
to
>>>>> create a document and a set of attachments without going through
>>>>> intermediate revisions.
>>>> I am doing this currently, the recent fix to mochiweb of the 1MB body
>>>> regression allows one to upload document + attachments in a single
>>>> revision -- you need to base64 the attachment and set the attributes,
>>>> but it works.  My dump/load code does it quite nicely.
>>>>>
>>>>
>>>> Regards,
>>>>
>>>> Jeff Hinrichs
>>>>
>>>
>> Regards,
>>
>> Jeff
>>
>
> MIME (multipurpose internet mail extensions) is originally an email
> specification. The basic idea is exactly the same for HTTP though in
> the tradition of RFC's I imagine there are special caveats when used
> in either context.
>
> The wiki looks to have some decent info as well as linked RFC's for
> different bits.
>
> [1] http://en.wikipedia.org/wiki/MIME#Multipart_messages
>
> HTH,
> Paul Davis
>

Whoops, reply not sent to the list.

Mime
View raw message