couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [REVIEW] CouchDB Replication Protocol
Date Tue, 12 Nov 2013 05:35:08 GMT
On Tuesday, November 12, 2013, Alexander Shorin wrote:

> Hi Jens!
> Thanks for looking into! Reply inlined
> On Tue, Nov 12, 2013 at 5:05 AM, Jens Alfke <<javascript:;>>
> wrote:
> > Thanks, Alexander.
> >
> > How would you like us to edit the source? I’ve never worked with
> > collaborative editing using gists. Does it work like source editing
> where I
> > fork it and send you a pull request?
> I was wrong thinking that working with gist is good way to go since
> there is not support for PR and I'll have to merge all the forks
> manually:
> so I've created regular git repository, so feel free to send PRs!

hrmmm why another repo? i have created the hacking repo on my github for
that... Or we can like we said put all in a couchdb branch and collaborate
via git/github. At least i thought we decided that...

> > In general it needs a lot of proofreading for English grammar.
> That's the thing I'm bad in ): Would be glad for help with it. If you
> in doubt what I have trying to say, I could try rephrase it, but
> probably with no better grammar ):
> > In general I have a feeling this whole process is a case of “the best
> being
> > the enemy of the good”. Something short like my original document would
> have
> > been fine, IMHO. It’s nice that you put so much effort into this, but
> it’s
> > now a very long document that’s going to take a long time to review.
> You're correct, but I found short version isn't much helpful for
> creating own peer. That's how and why I had started this document (:
> Yes, some main points are explained, but devil in details and I have
> to switch to wireshark and read couchdb logs with couch_replicator
> source code to understand why replication crushes and what peer should
> return on CouchDB request. On some point, that was reimplementing a
> part of CouchDB HTTP API, so I think it's possible to replace this
> document examples and text stuff with references to API endpoints
> definition. However, actually you don't have to implement whole API
> for GET /db/docid resource to have replication works, just some small
> part, so such references may only confuse more.

imo this doc amd others are here to prepare a full protocol spec, so we
have to find a way to make sure that  all implemtations will be able to
speak each other. ie the way endpoints are found on the transport should be
well defined. How it can work on different transports is the real question.
(and i think beeing restful and removing  any relation to an api would be

will review in another mail.

- benoît

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message