<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 6, 2013 at 10:53 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 08/06/2013 10:45 AM, David Chadwick wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
On 06/08/2013 14:46, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
API extensions are more hassle than anything else. Let us promote<br>
standards, not endless extensibility at the expense of usability.<br>
</blockquote>
<br>
This is the crux of the issue. Everyone who participates in<br>
standardisation meetings has their own agenda to follow: their<br>
preferences, likes, dislikes, must have features, etc. This is why<br>
standards end up with optional extensions.<br>
</blockquote>
<br></div>
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.<br>

<br>
Case in point: the HTTP extension framework:<br>
<br>
<a href="http://tools.ietf.org/html/rfc2774.html" target="_blank">http://tools.ietf.org/html/<u></u>rfc2774.html</a><br>
<br>
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.<br>
<br>
It doesn't make sense. Then, or now.<br>
<br>
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".</blockquote><div>
<br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
<br>
> If you dont have them, then<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
you cannot get buy in from sufficient stakeholders. If you do have them,<br>
then you end up with extensibility.<br>
<br>
But actually extensibility in my opinion is a "must have" feature, since<br>
no protocol or standard (or Keystone) remains static for ever, and new<br>
features are continually being added to it. Therefore you must have a<br>
way for clients to know what functionality the remote server currently<br>
supports so that it can talk the correct protocol flavour to it.<br>
</blockquote>
<br></div>
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.<br></blockquote><div><br></div><div>
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:</div>
<div><br></div><div>  <a href="https://github.com/openstack/identity-api/tree/master/openstack-identity-api/v3/src/markdown">https://github.com/openstack/identity-api/tree/master/openstack-identity-api/v3/src/markdown</a><br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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?<br>
</blockquote><div><br class="">That makes me cringe... API extensions shouldn't be treated as hacks! That's a cultural problem :(</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
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.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's a shame it doesn't keep it there.<div class="">
<div class="h5"><br>
<br>
Best,<br>
-jay<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>