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