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