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.