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


If the extension contradicts the specs, then I don't consider it to be an extension. In that case the spec isn't being extended it is being contradicted. OTOH, whether an extension is mandatory (for a particular platform) or not is a different issue. My suspicion is that since we are writing a spec that is language-, framework-, platform-independent we can't disallow mandatory extensions.

For example, let the platform be Java-based. The spec is going to define the PDP but cannot talk about Java-specific artifacts. A Java-based platform is going to necessarily need Java artifacts (jar/war/war/whatever-ar) within the PDP. Such a platform is going to define where these Java artifats are located within the PDP structure. Any PDP package that doesn't use the such a 'Java' extension is not going to work on that platform. I think the same goes for attributes and resource types.

I think the important thing for us to get it right is defining the right extension framework(s) for CAMP that draws appropriate lines around what is extensible and where and what isn't. Furthermore it ought to be very clear what is an extension and what isn't, so that users are clear on which parts are interoperable/portable and which aren't and why. I think it is also important to enable discoverability of extensions.

-Anish
--

On 01/16/2013 08:28 PM, GILBERT PILZ wrote:
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
<mailto: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]