Open Stack

On 08/06/2013 11:53 AM, 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? *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.

Interesting.  Dolph and I were just arguing on IRC if Certificates in 
support of PKI tokens belong in Extensions or in Core API.  While I was 
vehemently in support of core API, I could see his rationale for extensions.

Discoverability is one of the key mechanisms of the Web; the ability to 
deduce from the context where to go next.  However, that is much easier 
for humans than for automated processes.  Contracts, on the other hand, 
are bast for automated processes.



>
> Best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev