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 Tue, 24 Feb 2009 21:51:08 GMT
On Tue, Feb 24, 2009 at 4:05 PM, Damien Katz <damien@apache.org> wrote:
>
> 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.
>

That hadn't occurred to me. I kinda liked the attachments via
multipart mime so i was more forcing everything else into that format.
At the moment I can't decide which form I prefer. I definitely see
sticking to JSON being easier to parse all around, though.

On side note that makes me chuckle, going with headers would probably
push the _rev attribute into an Etag header, thus sidestepping the
renaming issue for that part of the API :D

Anyway, I'll let that percolate a bit and read some more of the db and
replication api's to try and get a better handle on all the different
bits that actually touch the _ metadata.

HTH,
Paul Davis

>>
>> 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.
>
> -Damien
>
>

Mime
View raw message