couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hinrichs - DM&T" <dunde...@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 01:09:46 GMT
On Thu, Feb 26, 2009 at 6:59 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> 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.
>
That explains my misunderstanding, I didn't realize it supported
binary.    My encounters to date have always been quoted-printable and
base64.  Thanks for the pointer!

Regards,

Jeff Hinrichs

Mime
View raw message