On Thu, Jan 8, 2009 at 2:59 PM, Antony Blakey <[email protected]> wrote: > > IMO the issue for PATCH is not working out what to do. The PMC have asserted > that no such mechanism will be incorporated unless the diff format is an > RFC/ID.
I don't recall any such PMC proclamation. I remember the opinions of a few comitters, but it would be absurd to reject good code based merely on the workings of a standards body. If you want to see PATCH in CouchDB, the best thing to do is add ASF code to the JIRA. We can't promise ahead of time that we'll apply it right away (or at all) but it would be a good next move. I think CouchDB should have PATCH (for update efficiency), but I'm happy to put that off for some time. People are still learning documented oriented best practices, and PATCH is enough like partial update, to give people the wrong idea about how to avoid document contention. Personally, PATCH seems like a post-1.0 feature. If a patch for PATCH were to come along, I'm sure the PMC would consider it seriously - the existence of an RFC for JSON-diff would not be the deciding factor in its adoption. Reducing on-the-wire weight is a noble cause, but encouraging devs to update documents more than they should is problematic in my opinion. CouchDB has a habit of manifesting to its clients, the costs it assumes in performing an operation. This is not the most efficient way to run, but it does make clear the modes of operation that won't make Couch the bottleneck at very large N and high concurrency. PATCH sets up an efficiency asymmetry by reducing network load, but not disk write load. I guess I'd advise against using PATCH while designing an app, but could see its utility in practice. -- Chris Anderson http://jchris.mfdz.com
