Hi Antony,
On 24 Feb 2009, at 00:34, Antony Blakey wrote:
<flamesuit on>
OTOH, one should use the correct term and not redefine existing
terms to suit one's own purpose. In a tangentially related way, the
use of the term RESTful wrt CouchDB is a marketing abomination.
</flamesuit off>
I've heard that before. CouchDB's core document API is as
RESTful as it gets. But not all of CouchDB's API is RESTful
and it wouldn't even make sense. I don't see any abomination
going on here. Thanks.
Your point behind the flame, not redefining existing terms:
The existing notion of a revision is that it is something you
can go back to. This is not what CouchDB revisions are, so
we are, right now, repurposing existing terminology.
I'm not saying, revision is wrong because it isn't. It's just not
a good choice for the API from a learning perspective. I under-
stand, that an API has more perspectives than learning it, so
we need to find out where to make the trade-off.
<toungeincheek>
We're violating rules 1, 5, 6, 13, 14, and 15, probably more of
Rusty's rules of hard to use interfaces,
http://www.pointy-stick.com/blog/2008/01/09/api-design-rusty-levels/
</toungeincheek>
The documentation about replication, the role of revisions, the lack
of inter-document consistency guarantees (including, crucially to
the operation model, the lack of Monotonic Write guarantees), really
needs to be expanded.
The consequences of CouchDB's underlying model aren't immediately
obvious, and should be spelled out, as I started to do here: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200902.mbox/%[email protected]%3e
- which was obviously in the context of changing that mechanism,
but still the explanation and references are useful.
The wiki is open for all and everybody here welcomes useful additions.
Cheers
Jan
--
