OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [camp] extensibility issues


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

On Jan 16, 2013, at 4:46 PM, GILBERT PILZ <gilbert.pilz@oracle.com>
 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]