On Tue, Aug 6, 2013 at 10:53 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 08/06/2013 10:45 AM, David Chadwick wrote: > >> >> >> On 06/08/2013 14:46, Jay Pipes wrote: >> >>> API extensions are more hassle than anything else. Let us promote >>> standards, not endless extensibility at the expense of usability. >>> >> >> This is the crux of the issue. Everyone who participates in >> standardisation meetings has their own agenda to follow: their >> preferences, likes, dislikes, must have features, etc. This is why >> standards end up with optional extensions. >> > > Which standards are you referring to? *Good* standards, like the HTTP or > ANSI SQL standards, just have a set of interfaces that correspond to a > version. It's only when vendors go outside of the standard to define what > they want when things get fuzzy. > > Case in point: the HTTP extension framework: > > http://tools.ietf.org/html/**rfc2774.html<http://tools.ietf.org/html/rfc2774.html> > > Last updated in the year 2000. Nobody uses or cares about it. Why? Because > it isn't a standard, and provides the ability for every Tom, Dick, and > Rackspace to reinvent their own HTTP interfaces. > > It doesn't make sense. Then, or now. > > The point of standards and standards committees is to come to a compromise > and develop a single standard. API Extensions are merely punting on that > responsibility in the name of "customization". First of all, I totally understand, appreciate and agree with your sentiment. Extensions are very frequently painful, but I'd argue that they don't have to be. > > > > If you dont have them, then > >> you cannot get buy in from sufficient stakeholders. If you do have them, >> then you end up with extensibility. >> >> But actually extensibility in my opinion is a "must have" feature, since >> no protocol or standard (or Keystone) remains static for ever, and new >> features are continually being added to it. Therefore you must have a >> way for clients to know what functionality the remote server currently >> supports so that it can talk the correct protocol flavour to it. >> > > Extensibility is only a must have for *implementations*, IMHO, not for the > *API*. API extensions are just a way around the hard work of creating a > good, standardized, well-documented API. > I especially don't see an "API extension" as a way to avoid producing well documented API's. For example, the accepted extensions to the v3 Identity API are fully documented from use case through API behavior: https://github.com/openstack/identity-api/tree/master/openstack-identity-api/v3/src/markdown > Case in point: The Nova API extensions. How many of them are: a) not > documented at all, including the code itself, b) not documented in some > online document somewhere, and c) directly contradict the functionality in > other extensions? > That makes me cringe... API extensions shouldn't be treated as hacks! That's a cultural problem :( > > Extensibility, at least in my view, belongs on the implementation/driver > layer. Keystone has done a good job keeping extensibility at its driver > layer so far. To be fair, extensibility at the driver layer is basically keystone's core use case: allowing OpenStack to take advantage of your identity data, wherever it is. > It's a shame it doesn't keep it there. > > > Best, > -jay > > > ______________________________**_________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.**org <OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev