On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams <[email protected] > wrote:
> > On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > > > On 08/06/2013 01:19 AM, Jamie Lennox wrote: > >> Hi all, > >> > >> Partially in response to the trusts API review in keystoneclient > >> (https://review.openstack.org/#/c/39899/ ) and my work on keystone API > >> version discoverability (spell-check disagrees but I'm going to assume > >> that's a word - https://review.openstack.org/#/c/38414/ ) I was > thinking > >> about how we should be able to know what/if an extension is available. I > >> even made a basic blueprint for how i think it should work: > >> > https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensionsand > then realized that GET /extensions is only a V2 API. > > > > I'm not certain that the extensions should really be in the v2 or v3. > It always seemed to me that Extensions should be parallel to, and separate > from, the core API. > > > I agree. Extensions should not be in core, but the mechanism by which > extensions are discovered should be part of the core...right? > Agree. The fact that you call GET /v2.0/extensions or GET /v3/extensions instead of GET /extensions just means that we can iterate on the "extensions" response itself, not necessarily that the extension *only* applies to particular version API being queried (that's a different issue). > > -jOrGe W. > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
