That's the crux of my question. What if a provider extends the spec
in such a way that one or more core use cases such as "instantiate
an application" cannot be executed without using the extension?
There are other, similar issues - such as extensions that contradict
the semantics defined by the spec.
~ gp
On 1/16/2013 5:21 PM, Mark Carlson wrote:
I think a few simple rules will suffice to allow implementation
extensions that don't break the core interoperability of the
standard.
Obviously you cannot use the extended functionality of an
extension unless the client is coded to it.
It must be OK to leave off/alone extended attributes, for example.
They might be mandatory to get the extended functionality, but
they should remain optional to get the core standard
functionality.
-- mark
On 1/16/13 6:07 PM, Adrian Otto
wrote:
Gil,
This is a good question. If what the provider wants to do
does not violate the specification, then it should be allowed.
When that proves to be problematic, we can address it in
future revisions of the spec. If they require specific
extensions to work with their implementations, I think that's
fine. It may reduce the ease of interoperability between their
service and other CAMP complaint services, but they would do
this consciously when it makes sense to accept that tradeoff.
Your question does suggest that perhaps there are some
things that should be explicitly prohibited. We should try to
include those in the extensibility section of the spec once
that is written. I'm really looking forward to getting that
put together.
Adrian
wrote:
One big issue with
extensibility involves the following question: Can a
CAMP provider define an extension that clients must
support in order to effectively use their
implementation? For example, can a provider extend the
Assembly Template resource to say that “all POSTs to
this resource must include the “zone” query parameter in
the URI …”?
If we do not allow this, some providers may have
difficulty matching the CAMP API to their underlying
system. If we do allow this, interoperability will be
weakened in that there may exist CAMP-compliant
implementations that a CAMP-compliant client cannot use
because it is does not support the required extension.
~ gp
|