On Aug 6, 2013, at 12:34 PM, Jay Pipes wrote: > On 08/06/2013 01:21 PM, David Chadwick wrote: >> >> >> On 06/08/2013 18:11, Jay Pipes wrote: >>> What SMTP, DNS and LDAP extensions are in use by systems that need to >>> interoperate in the same way that Keystone does? <-- This is a genuine >>> question, not sarcasm. I'm truly curious. >> >> Take SMTP for example. My Thunderbird client needs to know what >> authentication extensions are implemented by the POP3 server and SMTP >> server that it is talking to, in order to send and receive email in a >> secure manner. >> >> In the same way, once Keystone supports say federated login as an >> extension, a client will need to know if this extension is supported or >> not. If not, it wont be able to offer it to the end user. (It is not a >> sensible design for a client to send an extension protocol message to a >> server and get a 400 Bad Request response. This tells the client >> nothing. 501 Not Implemented might be a more informative response, but >> in this case the server has to know that an extension was requested and >> we have to document that this is the standard response to an >> unimplemented extension). > > Ah, OK, so I think we're actually closer to one another than first glance. > So, I *entirely* agree that if API extensions are available/supported by an > API, then there should be an easy way to discover those extensions -- > /endpoints is perfectly fine. > > I also agree that a *protocol* should have the flexibility, within its > bytestream construct, to extend its scope over time, *without needing to > change the underlying protocol*. So, for example, a protocol that leaves > itself some way of "growing" over time is, by nature, A Good Thing (tm). > > However, I do *not* believe that resource additions to a REST-ful API > necessitate a new API "extension" that must be treated like something that is > fundamentally different from the existing resources published in the API. > > Por ejemplo, > > I do not believe the adding a /regions resource should require me to add an > API "extension" just to add the resource to the API. I believe we should be > able to propose the adding of the /regions resource, debate it, and then add > it to a v3.x Keystone API. > > There isn't anything about a region resource that is fundamentally different > from some other resource managed by Keystone -- like domains or endpoints -- > and therefore I don't believe that adding a /regions resource endpoint should > require anything more than a bump in the version of the API. >
We should definitely have debates about what should be in core and what should be an extension. And I also agree that some features that are currently defined as extensions should probably be built into core. A lot of factors can come into play in the decision..How general or niche the feature is? How much support it has in the community? Whether or not it's possible for all implementations / deployments to support it etc. To say that something shouldn't be an extension simply because it's exposed as a resource though doesn't make sense to me. > Hope this makes more sense, > -jay > > p.s. Despite my opinion that /regions resource addition should not be an > extension, I'm still submitting a proposed API extension for it ;) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
