Open Stack

On 08/06/2013 12:57 PM, David Chadwick wrote:
>
>
> 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.

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.

Best,
-jay

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