couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: [RESULT]: Accept newline patch into CouchDB for 0.9 (Was: Re: VOTE: accept newline patch into CouchDB for 0.9)
Date Tue, 24 Feb 2009 21:05:59 GMT

On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
> I'm a fan of the no-metadata-in-documents concept, but there are some
> issues both philosophical and practical. Philosophically speaking, as
> pointed out by the HTTP headers thread, we may be abusing headers when
> we consider some of the more CouchDB specific concepts, I doubt that
> there's an existing header for everything we'd need.
> Secondly _attachments and _rev_info are unbounded. I know there are
> limits to the number of headers in a request I can only assume that
> some clients might have limits for responses.

Good points.

> The only thought I had that would satisfy most of the interesting bits
> I've come up against would be to have two response versions: the raw
> document body as we have now (minus metadata obviously) that includes
> the very basic _id and _rev in the headers (I'm assuming there are
> appropriate headers for these). And a second version that is a
> multipart mime message that has parts corresponding to the doc body,
> the longer metadata like _revs_info and then one part per attachment.
> Including the different parts could be optional. And so far that's
> missing some stuff like listing attachment info without getting the
> entire body.

Sounds interesting.

> The real kicker is how do we support clients lacking HTTP-fu. For
> instance, a quick google [1] suggests that XHR probably isn't capable
> of dealing with multipart messages.

Stupid reality!

> There's an obvious middle ground
> that could allow different versions to be returned via URL parameters
> though, and then maybe provide the "all content as multipart mime" as
> an option.

There could be a format where all the metadata is returned in the top  
level json object, and the json body is returned as a body field.

> Anyway, that's about as far as I've thought through the different  
> issues.

Right. I've alway thought it might be a good idea to do something like  
this, but there are lots of small issues to work through. I hope  
someone tries, I'd like to see if its workable in practice.


View raw message