Open Stack

On 06/08/2013 16:53, Jay Pipes 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?

Virtually all standards from every standards organisations OASIS, IETF, 
ISO etc.
e.g. SMTP is ubiquitous yet it has dozens of extensions. The DNS and 
LDAP have multiple extensions as well. So you can and need to have 
extensions and that does not stop a standard from gaining wide 
acceptance and applicability.


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

No, you need extensibility in the protocols as well.
Cases in point, SMTP and LDAP.

regards

David

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