[OASIS Issue Tracker] Commented: (CAMP-40) version array resource/thing has a number of problems

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32643#action_32643 ] 

Roshan Agrawal commented on CAMP-40:
------------------------------------

1. We should decouple the concept of backward compatibility from major vs minor version i.e. it is not necessary that minor version upgrades will be backward compatible; in the same vein, it is not necessary that major version upgrades will break clients on previous version.

2. When the platform publishes the list of "available versions", we need to clarify the semantics of what it means i.e. it is that clients that confirm to any of the listed versions can communicate with the platform? In other words, all the listed versions ensure backward compatibility with each other

3. ImplementationVersion: there might be value in having this - given we state CAMP spec is a humble spec and providers will end up implementing extensions to realize a full PaaS, is it not possible that for an implementation of a given camp spec version, there are enough differences in the extensions used in the implementation revisions, such that the revisions are not backward compatible with each other. 

> version array resource/thing has a number of problems
> -----------------------------------------------------
>
>                 Key: CAMP-40
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-40
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> There are a couple of problems with the version array resource/thing defined in section 6.8.
> 1.) Unlike all the other things you can use HTTP GET to retrieve, the array of available versions is not defined as a first-class resource (i.e. it has no "type", "uri", "name", etc.) In the interests of simplicity it would be better if clients didn't have to special case the code that retrieves the version array.
> 2.) Placing the version array resource "under" the platform resource (i.e. at <platform-url>/api/versions) creates an inherent aliasing problem. For example, suppose a provider concurrently supported by CAMP 1.1 and CAMP 1.2. They might have a "Versions" resource that looked like the following:
> [
>   { "version" : "1.1", "href" : "http://camp.example.org/1.1";, "name" : "nCAMP 0.9 POC" },
>   { "version" : "1.2", "href" : "http://camp.example.org/1.2";, "name" : "BaseCAMP 1.0" }
> ]
> Should a client expect to be able to retrieve this resource through either "http://camp.example.org/1.1/api/versions"; or "http://camp.example.org/1.2/api/versions"; ? Should a client expect the representation of the resource at "http://camp.example.org/1.1/api/versions"; to be the same (baring any unexpected updates) as the representation of the resource at "http://camp.example.org/1.2/api/versions";? If we did decide to represent the version array as a first-class resource, what should the value of its "uri" attribute be?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira