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
|