On Tue, Feb 24, 2009 at 4:05 PM, Damien Katz <[email protected]> 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 > >
