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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev