couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Fail on a simple case on replication
Date Tue, 24 Feb 2009 10:32:38 GMT
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/%3c0FDDC57C-DB78-4241-86DE-549FECC8B558@gmail.com%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
--


Mime
View raw message