Open Stack

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

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".

 > 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.

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?

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. It's a shame it doesn't keep it there.

Best,
-jay