On Fri, Jul 22, 2011 at 11:26, Randall Leeds <randall.le...@gmail.com> wrote: > On Fri, Jul 22, 2011 at 09:40, Benoit Chesneau <bchesn...@gmail.com> wrote: >> On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana >> <fdman...@apache.org> wrote: >>> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bchesn...@gmail.com> >>> wrote: >>>> >>>> Yup, but I think that's a bug then. I shouldn't have to set any >>>> userctx imo. If no admin has been set, every user is an admin except >>>> if we change the default behavior and then it's not consistent. >>> >>> This was discussed sometime before the 1.1.0 release in the security list. >>> And it's a principle of the least privileges by default (roles is an >>> empty list). >>> >>> >> I've no problem with that, it's even good. But other part of the API >> aren't consistent then. While _replicator is ok, I can still do this >> operation on _replicate. I propose to port the same behavior >> _replicate.OK for that? > > I'd definitely prefer they be consistent. > In fact, I've been arguing quietly for POST to _replicator to be > exactly the _replicate API and to deprecate the latter. > Isn't this possible? >
What I mean to say is that I think it's absolute craziness to have two replication APIs. {persist: true} or something would have made more sense to me. ?block=true perhaps if we want the old one-shot, blocking. Persist on PUT or with {id: <replication_name>}, otherwise make it one-shot. I hate to be complaining like this after we've already released it with a different API, but I raised this a few times before 1.1 went out. I think two APIs for replication is ugly and confusing. A new CouchDB user has enough to digest without having to remember that _replicate is different from _replicator. I would have preferred we papered over the differences as described above and made _replicate use a database, rather than create a brand new path. </rant>