While it's exciting to be bike-shedding so vigoriously, my mind keeps coming back to the things we could do to make CouchDB rock:
Full Unicode database and design doc name handling: I think flexible database urls are worthy goal. We still need to figure out how this will look on the file system. (Antony, any luck on the name stubs?) Here's a related ticket asking for VERSION files inside the db directories to help Debian warn against incompatible upgrades: http://issues.apache.org/jira/browse/COUCHDB-44 Also related: http://issues.apache.org/jira/browse/COUCHDB-168 (configurable derived data storage directory). OMG error handling: I think Couch has some good code here - the JSON error messages gives us a strong start. I'm working on normalizing the error handling from JavaScript processes, so that validation, form and view development gets easier. There's also a call for start up warnings about file permissions and port availability (oh and the fact that old versions of Erlang are unusable). And no room to write to disk: http://issues.apache.org/jira/browse/COUCHDB-164 Perhaps we need some documentation for ourselves about how errors are bubbled through the system. We're very close, but there are some inconsistencies from various modules, I'm afraid. We need to document forms and the new '%2F'-free urls moreso than just in couch_tests.js. I was also thinking it'd be slick to set up redirects from the '%2F' versions back to their '/' counterparts, but serving the content at both locations works for now. Jan has some other good ones here: "Another thing is an ignore_errors=true option for bulk operations for people who can live with failing writes. In addition, it would be nice when a bulk operation fails, the failing document id would be included in the response." As long as we don't try to return the list of all the updates that would have failed had we tried to continue the operation, returning the first failed updates' id would make ammended retries feasible. There's a big difference between ignore_errors and transactional=false, so we should be clear on what guarantees CouchDB will provide. Fixing `descending=true` and the whole startkey & endkey swap. There's a major n00b WTF there. I think in this case, an suprisingly empty view result is not the best addition to the learning curve. Also view etags: With the new view group state servers we're within striking distance of view etags, although it's a bit deeper in the codebase than a lot of this stuff. View etags would have to factor in the db's current seq (or more cache-efficiently, the views last-modified-seq, but that can wait) as well as some details about the request and the design document. I'm sure there's more than this to do, but this is more than enough to keep all of us busy if we want. -- Chris Anderson http://jchris.mfdz.com
