Open Stack

On Tue, Aug 6, 2013 at 10:53 AM, Jay Pipes <jaypipes at 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 at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130806/498ca3f4/attachment.html>