CAMP extensibility issue

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

There are a several extensibility issues with CAMP 1.0 spec. To kick off a discussion, my thoughts on various extensibility points in the spec are listed below.

Comments are most welcome.

-Anish
--

CAMP Extensibility Issue

1. Introduction

CAMP specification mentions extensibility in various places in the specification but does not say how
one is meant to extend the specification. Typically specifications like CAMP achieve a balance between
portability/interoperability/conformance and the ability to provide a working implementation, as well
as innovation, by creating an extensibility framework that draws a line around what is defined in the
specification and rules on how/where implementations can create extensions. Annex C provides an
example of a Database Platform Component extension.

2. Issue

There are several places where an implementation may want to create extensions. Although the specification mentions extensions, this issue is about the fact that there is no extension framework for CAMP defined. In addition, typically, specifications not only specify where/how the extensions are created but also address discoverability and management of extensions. There are several sub-issues
related to extensions:

1. Adding new attributes to a resource defined in the specification. For example, an Application Component may want to provide details about resource usage via additional attribute values.
2. An implementation may want to create additional resource types such as the one mentioned in Annex C.
3. An implementation may want to provide alternate additional serialization formats, for example XML, via HTTP content negotiation.
4. An implementation may want to extend the life cycle model by adding additional states. For example, an additional optional state called 'verified and virus-scanned'.
5. An implementation may want to extend the life cycle model by adding additional transition between existing states. Eg., from an instantiated application and the 'deleted' end state.
6. A vendor may want to extend the protocol to include additional operations. For example, a request to virus-scan a PDP.
7. A vendor may want to extend the PDP specification. For example, a Java EE app may want to specify additional metadata in the PDP.
8. A vendor may want to extend the list of error code specified in section 5.4.
9. One does one discover/query extensions supported by a particular vendor.
10. How/where does clients/servers/messages indicate, if applicable, which extension is in use.
11. How is distributed development and implementation of extensions is managed. This is needed so that multiple extensions, for example, do not create identical syntactic extensions that have different semantic meanings. Typically this requires appropriate management, rules, or a central repository for name spaces and partitioning of symbol spaces.