Re: [camp] extensibility issues

[Tobias Kunze <tkunze@redhat.com>]

+1 

On Jan 18, 2013, at 0:03, Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:

> 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
>>>> 
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php