On Thu, Feb 26, 2009 at 6:59 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Thu, Feb 26, 2009 at 7:58 PM, Paul Davis <paul.joseph.da...@gmail.com> > wrote: >> On Thu, Feb 26, 2009 at 7:37 PM, Jeff Hinrichs - DM&T >> <dunde...@gmail.com> wrote: >>> On Thu, Feb 26, 2009 at 9:47 AM, Paul Davis <paul.joseph.da...@gmail.com> >>> wrote: >>>> On Thu, Feb 26, 2009 at 8:42 AM, Jeff Hinrichs - DM&T >>>> <dunde...@gmail.com> wrote: >>>>> On Thu, Feb 26, 2009 at 3:56 AM, Jan Lehnardt <j...@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
