On Thu, Dec 4, 2008 at 4:01 AM, Matt Goodall <[EMAIL PROTECTED]> wrote: > I'm aware that some are significant changes and would break language > bindings but better now than post 1.0!
I'll try to answer without regard for breaking changes that would be the result. > > = Document Revisions = > > Identify document revision using a segment arg instead of query param, e.g. > I think the current ?rev=revstring approach is nice because in the normal case, you'll be requesting the attachment without a rev specified (eg you just want the latest). Standard query params are also a little easier to deal with both in client libraries and in Mochiweb. > > = Document Bits = > > > = Reserved Names = > > Following on from "Document Bits", would it be sensible to reserve > *all* path segments beginning with an underscore for CouchDB's use? > This is worth at least thinking about. Having the _attachments path would open the door to an attachments index view, as well as attachments with literal '/' in the name. What do people think of the _attachment path as a way out of the %2F dilemma? > > = View API - start/end pairs = > > Would it make sense to combine the startXXX and endXXX pairs into a > single range query param. Doesn't make sense. 90% of the time I specify a startkey without an endkey or vice versa. > > = View API - map/reduce/rereduce control = > "map" => reduce=false > "reduce" => reduce=true&group=true > "rereduce" => reduce=true&group=false > It's a little more complex than that, and built with future extensibility in mind. For instance, you can have more than one named reduce per map function, eventually, by using built-in erlang views. eg: reduce=sum or reduce=row_count. -- Chris Anderson http://jchris.mfdz.com
