You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Joan Touzet <wo...@apache.org> on 2013/06/05 00:40:35 UTC
[PROPOSAL] Capability identification
Today, if I GET http://localhost:5984/ , I get:
{"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
Apache Software Foundation"}}
If I GET from http://mozauto.iriscouch.com/ , I get:
{"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
Couch"}}
And if I GET http://wohali.cloudant.com/ , I get:
{"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
I believe I get further still different responses from Pouch and Touch
and other CouchDB-alikes, provided they even have an equivalent of
GET /.
Long ago, in a galaxy far far away, the developers of Internet Relay
Chat daemons faced a similar problem. While they were bound by a single
RFC (and later, its twin), each developer wanted to extend the program
in interesting and unique ways. Some of those features became
commonplace and built a shared understanding, others were unique
capabilities of specific implementations, and yet others indicated
specific incompatibilities introduced for nefarious purposes.
While the sordid history of the IRC protocol is a topic for drinks after
a meetup some night, one lesson learned has proved exceedingly useful:
the CAPAB string. Documented in the TS6 specification[1] but universally
adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
implemented functionality as well as services offered. A further
extension was created for client-to-server capabiliity negotiation
as a draft RFC[2][4] and is also widely implemented.
To make this more tangible, reference this list[3] of IRC server
CAPABilities. If you've ever used IRC, and especially different IRC
networks, you should be able to intuitively understand how this up-front
negotiation helps simplify server-to-server connection negotiation.
---
I think CouchDB should extend its identification in the root-level
document with a capability advertisement. This would help prevent the
current anti-patterns in production use of CouchDB:
1. Client library negotiation based exclusively on "compatibility
with >= version of Apache CouchDB," which is nebulously documented
at best.
2. Provide a clear means by which CouchDB plugins and CouchDB-alike
services can advertise their availability.
3. Provide a way for alternate implementations of similar
functionality to indicate interoperability.
4. Possibly simplify the replicator (though this is a special case of
1 and 2 above).
I've gotten no further than this in my thinking yet; I didn't want to
start implementation before folks had a chance to say whether they
thought it'd be a good idea or not.
[1]:
https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
[2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
[3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
[4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Russell Branca <ch...@apache.org>.
+1
This sounds like a good path for letting all the different implementations
work together, and also for allowing each to provide different or custom
interfaces, especially looking down the road at the eventual plugin system.
I'm also very intrigued by the idea of non CouchDB systems being able to
advertise capabilities for subsets of CouchDB functionality. So for
instance a random third party service being able to speak the replication
protocol and advertising that.
-Russell
On Tue, Jun 4, 2013 at 6:35 PM, Randall Leeds <ra...@gmail.com>wrote:
> +1
>
> On Tue, Jun 4, 2013 at 3:40 PM, Joan Touzet <wo...@apache.org> wrote:
> > Today, if I GET http://localhost:5984/ , I get:
> >
> >
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> > Apache Software Foundation"}}
> >
> > If I GET from http://mozauto.iriscouch.com/ , I get:
> >
> >
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> > Couch"}}
> >
> > And if I GET http://wohali.cloudant.com/ , I get:
> >
> > {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
> >
> > I believe I get further still different responses from Pouch and Touch
> > and other CouchDB-alikes, provided they even have an equivalent of
> > GET /.
> >
> > Long ago, in a galaxy far far away, the developers of Internet Relay
> > Chat daemons faced a similar problem. While they were bound by a single
> > RFC (and later, its twin), each developer wanted to extend the program
> > in interesting and unique ways. Some of those features became
> > commonplace and built a shared understanding, others were unique
> > capabilities of specific implementations, and yet others indicated
> > specific incompatibilities introduced for nefarious purposes.
> >
> > While the sordid history of the IRC protocol is a topic for drinks after
> > a meetup some night, one lesson learned has proved exceedingly useful:
> > the CAPAB string. Documented in the TS6 specification[1] but universally
> > adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> > implemented functionality as well as services offered. A further
> > extension was created for client-to-server capabiliity negotiation
> > as a draft RFC[2][4] and is also widely implemented.
> >
> > To make this more tangible, reference this list[3] of IRC server
> > CAPABilities. If you've ever used IRC, and especially different IRC
> > networks, you should be able to intuitively understand how this up-front
> > negotiation helps simplify server-to-server connection negotiation.
> >
> > ---
> >
> > I think CouchDB should extend its identification in the root-level
> > document with a capability advertisement. This would help prevent the
> > current anti-patterns in production use of CouchDB:
> >
> > 1. Client library negotiation based exclusively on "compatibility
> > with >= version of Apache CouchDB," which is nebulously documented
> > at best.
> >
> > 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> > services can advertise their availability.
> >
> > 3. Provide a way for alternate implementations of similar
> > functionality to indicate interoperability.
> >
> > 4. Possibly simplify the replicator (though this is a special case of
> > 1 and 2 above).
> >
> > I've gotten no further than this in my thinking yet; I didn't want to
> > start implementation before folks had a chance to say whether they
> > thought it'd be a good idea or not.
> >
> > [1]:
> > https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> > [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> > [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> > [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
> >
> > --
> > Joan Touzet | joant@atypical.net | wohali everywhere else
>
Re: [PROPOSAL] Capability identification
Posted by Randall Leeds <ra...@gmail.com>.
+1
On Tue, Jun 4, 2013 at 3:40 PM, Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
> While the sordid history of the IRC protocol is a topic for drinks after
> a meetup some night, one lesson learned has proved exceedingly useful:
> the CAPAB string. Documented in the TS6 specification[1] but universally
> adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> implemented functionality as well as services offered. A further
> extension was created for client-to-server capabiliity negotiation
> as a draft RFC[2][4] and is also widely implemented.
>
> To make this more tangible, reference this list[3] of IRC server
> CAPABilities. If you've ever used IRC, and especially different IRC
> networks, you should be able to intuitively understand how this up-front
> negotiation helps simplify server-to-server connection negotiation.
>
> ---
>
> I think CouchDB should extend its identification in the root-level
> document with a capability advertisement. This would help prevent the
> current anti-patterns in production use of CouchDB:
>
> 1. Client library negotiation based exclusively on "compatibility
> with >= version of Apache CouchDB," which is nebulously documented
> at best.
>
> 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> services can advertise their availability.
>
> 3. Provide a way for alternate implementations of similar
> functionality to indicate interoperability.
>
> 4. Possibly simplify the replicator (though this is a special case of
> 1 and 2 above).
>
> I've gotten no further than this in my thinking yet; I didn't want to
> start implementation before folks had a chance to say whether they
> thought it'd be a good idea or not.
>
> [1]:
> https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Noah Slater <ns...@apache.org>.
Big +1
On 5 June 2013 19:36, Jan Lehnardt <ja...@apache.org> wrote:
> +1, excellent proposal.
>
> On Jun 5, 2013, at 00:40 , Joan Touzet <wo...@apache.org> wrote:
>
> > Today, if I GET http://localhost:5984/ , I get:
> >
> >
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> > Apache Software Foundation"}}
> >
> > If I GET from http://mozauto.iriscouch.com/ , I get:
> >
> >
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> > Couch"}}
> >
> > And if I GET http://wohali.cloudant.com/ , I get:
> >
> > {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
> >
> > I believe I get further still different responses from Pouch and Touch
> > and other CouchDB-alikes, provided they even have an equivalent of
> > GET /.
> >
> > Long ago, in a galaxy far far away, the developers of Internet Relay
> > Chat daemons faced a similar problem. While they were bound by a single
> > RFC (and later, its twin), each developer wanted to extend the program
> > in interesting and unique ways. Some of those features became
> > commonplace and built a shared understanding, others were unique
> > capabilities of specific implementations, and yet others indicated
> > specific incompatibilities introduced for nefarious purposes.
> >
> > While the sordid history of the IRC protocol is a topic for drinks after
> > a meetup some night, one lesson learned has proved exceedingly useful:
> > the CAPAB string. Documented in the TS6 specification[1] but universally
> > adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> > implemented functionality as well as services offered. A further
> > extension was created for client-to-server capabiliity negotiation
> > as a draft RFC[2][4] and is also widely implemented.
> >
> > To make this more tangible, reference this list[3] of IRC server
> > CAPABilities. If you've ever used IRC, and especially different IRC
> > networks, you should be able to intuitively understand how this up-front
> > negotiation helps simplify server-to-server connection negotiation.
> >
> > ---
> >
> > I think CouchDB should extend its identification in the root-level
> > document with a capability advertisement. This would help prevent the
> > current anti-patterns in production use of CouchDB:
> >
> > 1. Client library negotiation based exclusively on "compatibility
> > with >= version of Apache CouchDB," which is nebulously documented
> > at best.
> >
> > 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> > services can advertise their availability.
> >
> > 3. Provide a way for alternate implementations of similar
> > functionality to indicate interoperability.
> >
> > 4. Possibly simplify the replicator (though this is a special case of
> > 1 and 2 above).
> >
> > I've gotten no further than this in my thinking yet; I didn't want to
> > start implementation before folks had a chance to say whether they
> > thought it'd be a good idea or not.
> >
> > [1]:
> > https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> > [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> > [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> > [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
> >
> > --
> > Joan Touzet | joant@atypical.net | wohali everywhere else
>
>
--
NS
Re: [PROPOSAL] Capability identification
Posted by Jan Lehnardt <ja...@apache.org>.
+1, excellent proposal.
On Jun 5, 2013, at 00:40 , Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
> While the sordid history of the IRC protocol is a topic for drinks after
> a meetup some night, one lesson learned has proved exceedingly useful:
> the CAPAB string. Documented in the TS6 specification[1] but universally
> adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> implemented functionality as well as services offered. A further
> extension was created for client-to-server capabiliity negotiation
> as a draft RFC[2][4] and is also widely implemented.
>
> To make this more tangible, reference this list[3] of IRC server
> CAPABilities. If you've ever used IRC, and especially different IRC
> networks, you should be able to intuitively understand how this up-front
> negotiation helps simplify server-to-server connection negotiation.
>
> ---
>
> I think CouchDB should extend its identification in the root-level
> document with a capability advertisement. This would help prevent the
> current anti-patterns in production use of CouchDB:
>
> 1. Client library negotiation based exclusively on "compatibility
> with >= version of Apache CouchDB," which is nebulously documented
> at best.
>
> 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> services can advertise their availability.
>
> 3. Provide a way for alternate implementations of similar
> functionality to indicate interoperability.
>
> 4. Possibly simplify the replicator (though this is a special case of
> 1 and 2 above).
>
> I've gotten no further than this in my thinking yet; I didn't want to
> start implementation before folks had a chance to say whether they
> thought it'd be a good idea or not.
>
> [1]:
> https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Joan Touzet <wo...@apache.org>.
On Wed, Jun 05, 2013 at 03:03:04AM +0400, Alexander Shorin wrote:
> +1
>
> I'd like also add JIRA issue for reference:
> https://issues.apache.org/jira/browse/COUCHDB-1285
Thanks, I'd missed that one. Looks like the plumbing is on the way
there.
> So your proposal is actually on-half is done. The only missed thing is
> modules (CAPs) info which I believe be more actual after rcouch merge.
There's a bit more to what I've said here. I think it might be useful to
define a (very simple!) process by which the namespace is administered.
Or, at the very least, some guidelines on how to document what
advertising a given module means. In short, it should be possible to
have two totally different implementations of the same functionality,
agree on the CAPAB, but also indicate that they're supplide by different
modules.
I want to avoid the "everyone calls themselves Mozilla in the user-agent
string" problem, but allow a way of saying, for example: "Yes, I also
provide a view server that speaks JavaScript! No, I'm not actually
couchjs."
-Joan
> --
> ,,,^..^,,,
>
>
> On Wed, Jun 5, 2013 at 2:40 AM, Joan Touzet <wo...@apache.org> wrote:
> > Today, if I GET http://localhost:5984/ , I get:
> >
> > {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> > Apache Software Foundation"}}
> >
> > If I GET from http://mozauto.iriscouch.com/ , I get:
> >
> > {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> > Couch"}}
> >
> > And if I GET http://wohali.cloudant.com/ , I get:
> >
> > {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
> >
> > I believe I get further still different responses from Pouch and Touch
> > and other CouchDB-alikes, provided they even have an equivalent of
> > GET /.
> >
> > Long ago, in a galaxy far far away, the developers of Internet Relay
> > Chat daemons faced a similar problem. While they were bound by a single
> > RFC (and later, its twin), each developer wanted to extend the program
> > in interesting and unique ways. Some of those features became
> > commonplace and built a shared understanding, others were unique
> > capabilities of specific implementations, and yet others indicated
> > specific incompatibilities introduced for nefarious purposes.
> >
> > While the sordid history of the IRC protocol is a topic for drinks after
> > a meetup some night, one lesson learned has proved exceedingly useful:
> > the CAPAB string. Documented in the TS6 specification[1] but universally
> > adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> > implemented functionality as well as services offered. A further
> > extension was created for client-to-server capabiliity negotiation
> > as a draft RFC[2][4] and is also widely implemented.
> >
> > To make this more tangible, reference this list[3] of IRC server
> > CAPABilities. If you've ever used IRC, and especially different IRC
> > networks, you should be able to intuitively understand how this up-front
> > negotiation helps simplify server-to-server connection negotiation.
> >
> > ---
> >
> > I think CouchDB should extend its identification in the root-level
> > document with a capability advertisement. This would help prevent the
> > current anti-patterns in production use of CouchDB:
> >
> > 1. Client library negotiation based exclusively on "compatibility
> > with >= version of Apache CouchDB," which is nebulously documented
> > at best.
> >
> > 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> > services can advertise their availability.
> >
> > 3. Provide a way for alternate implementations of similar
> > functionality to indicate interoperability.
> >
> > 4. Possibly simplify the replicator (though this is a special case of
> > 1 and 2 above).
> >
> > I've gotten no further than this in my thinking yet; I didn't want to
> > start implementation before folks had a chance to say whether they
> > thought it'd be a good idea or not.
> >
> > [1]:
> > https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> > [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> > [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> > [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
> >
> > --
> > Joan Touzet | joant@atypical.net | wohali everywhere else
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Alexander Shorin <kx...@gmail.com>.
+1
I'd like also add JIRA issue for reference:
https://issues.apache.org/jira/browse/COUCHDB-1285
So your proposal is actually on-half is done. The only missed thing is
modules (CAPs) info which I believe be more actual after rcouch merge.
--
,,,^..^,,,
On Wed, Jun 5, 2013 at 2:40 AM, Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
> While the sordid history of the IRC protocol is a topic for drinks after
> a meetup some night, one lesson learned has proved exceedingly useful:
> the CAPAB string. Documented in the TS6 specification[1] but universally
> adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> implemented functionality as well as services offered. A further
> extension was created for client-to-server capabiliity negotiation
> as a draft RFC[2][4] and is also widely implemented.
>
> To make this more tangible, reference this list[3] of IRC server
> CAPABilities. If you've ever used IRC, and especially different IRC
> networks, you should be able to intuitively understand how this up-front
> negotiation helps simplify server-to-server connection negotiation.
>
> ---
>
> I think CouchDB should extend its identification in the root-level
> document with a capability advertisement. This would help prevent the
> current anti-patterns in production use of CouchDB:
>
> 1. Client library negotiation based exclusively on "compatibility
> with >= version of Apache CouchDB," which is nebulously documented
> at best.
>
> 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> services can advertise their availability.
>
> 3. Provide a way for alternate implementations of similar
> functionality to indicate interoperability.
>
> 4. Possibly simplify the replicator (though this is a special case of
> 1 and 2 above).
>
> I've gotten no further than this in my thinking yet; I didn't want to
> start implementation before folks had a chance to say whether they
> thought it'd be a good idea or not.
>
> [1]:
> https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, Jun 7, 2013 at 3:07 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> Well capababilities idea come from the SMTP world at first but same
> idea. That's indeed a good idea. Identification per see would't be
> efficient on a client level. We don't really want to reproduce the
> nightmare we have with the browsers with different U/A. Testing
> capabilities is definitely a good way to test what an endpoint
> support. For example some endpoint or node could only support the
> replication. one ather could support the couchdb/1.3 api. other could
> offers some extensions or plugin like you say.
>
> Though In these days I would modernize it a little as a way to
> describe the api endpoints with the resource supported.
>
> We could base it on the host metadata rfc [1] or using some new stuffs
> like the JSON api [2] .
>
> [1] http://tools.ietf.org/html/rfc6415
> [2] http://jsonapi.org/
I've been watching the jsonapi page and I quite like this idea.
Re: [PROPOSAL] Capability identification
Posted by Benoit Chesneau <bc...@gmail.com>.
Well capababilities idea come from the SMTP world at first but same
idea. That's indeed a good idea. Identification per see would't be
efficient on a client level. We don't really want to reproduce the
nightmare we have with the browsers with different U/A. Testing
capabilities is definitely a good way to test what an endpoint
support. For example some endpoint or node could only support the
replication. one ather could support the couchdb/1.3 api. other could
offers some extensions or plugin like you say.
Though In these days I would modernize it a little as a way to
describe the api endpoints with the resource supported.
We could base it on the host metadata rfc [1] or using some new stuffs
like the JSON api [2] .
[1] http://tools.ietf.org/html/rfc6415
[2] http://jsonapi.org/
Maybe there are other specs around. Anyway it also means we need to
describe our API accurately and what we support so expectation are
guaranteed. So if i noow that this server is couchdb 1.1 compatible i
don't have to test the vendor, like I now have to do in couchdbkit or
couchbeam to handle cloudant and couchdb nodes for small changes.
Instead I could just lod the capabilities and make sure to make them
available at the client level. We could also make a compatibility grid
later for the users based on capabilities.
- benoit
On Wed, Jun 5, 2013 at 12:40 AM, Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
> While the sordid history of the IRC protocol is a topic for drinks after
> a meetup some night, one lesson learned has proved exceedingly useful:
> the CAPAB string. Documented in the TS6 specification[1] but universally
> adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> implemented functionality as well as services offered. A further
> extension was created for client-to-server capabiliity negotiation
> as a draft RFC[2][4] and is also widely implemented.
>
> To make this more tangible, reference this list[3] of IRC server
> CAPABilities. If you've ever used IRC, and especially different IRC
> networks, you should be able to intuitively understand how this up-front
> negotiation helps simplify server-to-server connection negotiation.
>
> ---
>
> I think CouchDB should extend its identification in the root-level
> document with a capability advertisement. This would help prevent the
> current anti-patterns in production use of CouchDB:
>
> 1. Client library negotiation based exclusively on "compatibility
> with >= version of Apache CouchDB," which is nebulously documented
> at best.
>
> 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> services can advertise their availability.
>
> 3. Provide a way for alternate implementations of similar
> functionality to indicate interoperability.
>
> 4. Possibly simplify the replicator (though this is a special case of
> 1 and 2 above).
>
> I've gotten no further than this in my thinking yet; I didn't want to
> start implementation before folks had a chance to say whether they
> thought it'd be a good idea or not.
>
> [1]:
> https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Adam Kocoloski <ko...@apache.org>.
As the author of one of those replicator UA-sniffing compatibility hacks I definitely think a system for advertising capabilities is a Good Idea :)
Adam
On Jun 4, 2013, at 6:40 PM, Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
> While the sordid history of the IRC protocol is a topic for drinks after
> a meetup some night, one lesson learned has proved exceedingly useful:
> the CAPAB string. Documented in the TS6 specification[1] but universally
> adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
> implemented functionality as well as services offered. A further
> extension was created for client-to-server capabiliity negotiation
> as a draft RFC[2][4] and is also widely implemented.
>
> To make this more tangible, reference this list[3] of IRC server
> CAPABilities. If you've ever used IRC, and especially different IRC
> networks, you should be able to intuitively understand how this up-front
> negotiation helps simplify server-to-server connection negotiation.
>
> ---
>
> I think CouchDB should extend its identification in the root-level
> document with a capability advertisement. This would help prevent the
> current anti-patterns in production use of CouchDB:
>
> 1. Client library negotiation based exclusively on "compatibility
> with >= version of Apache CouchDB," which is nebulously documented
> at best.
>
> 2. Provide a clear means by which CouchDB plugins and CouchDB-alike
> services can advertise their availability.
>
> 3. Provide a way for alternate implementations of similar
> functionality to indicate interoperability.
>
> 4. Possibly simplify the replicator (though this is a special case of
> 1 and 2 above).
>
> I've gotten no further than this in my thinking yet; I didn't want to
> start implementation before folks had a chance to say whether they
> thought it'd be a good idea or not.
>
> [1]:
> https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [PROPOSAL] Capability identification
Posted by Jason Smith <ja...@gmail.com>.
On Wed, Jun 5, 2013 at 5:40 AM, Joan Touzet <wo...@apache.org> wrote:
> Today, if I GET http://localhost:5984/ , I get:
>
>
> {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>
> If I GET from http://mozauto.iriscouch.com/ , I get:
>
>
> {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>
> And if I GET http://wohali.cloudant.com/ , I get:
>
> {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>
> Long ago, in a galaxy far far away, the developers of Internet Relay
> Chat daemons faced a similar problem. While they were bound by a single
> RFC (and later, its twin), each developer wanted to extend the program
> in interesting and unique ways. Some of those features became
> commonplace and built a shared understanding, others were unique
> capabilities of specific implementations, and yet others indicated
> specific incompatibilities introduced for nefarious purposes.
>
Chris Anderson used to say, "IRC is the only network which can tolerate
netsplits. Also, it is the only network that has netsplits."
:P
Anyway, I really like this idea. It will be easy to implement in a
federated way (everybody fleshes out their own implementation, plus central
work on ASF CouchDB). And maybe this could even encourage feature
development. Instead of a nasty "nonstandard fork" I can work on a pleasant
"new capability."
Great example: https://github.com/iriscouch/pingquery_couchdb
I exercise this from probe_couchdb I don't even remember how I test for
compatibility.
What is the starting point? If I just brainstorm a list of potential
capabilities to this thread, does that help anybody?