[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (CAMP-40) version array resource/thing has a number of problems
[ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32661#action_32661 ]
Gilbert Pilz edited comment on CAMP-40 at 3/6/13 12:54 PM:
-----------------------------------------------------------
In addition to listing "backwardCompatibleSpecificationVersions" and "backwardCompatibleImplementationVersions" to the Platform resource, I'd also like the TC to consider changing the nature of the Versions resource. Rather than explicitly tying what is essentially a list of links to Platform resources to the spec and implementation versions supported by those Platforms - we should just call it what it is, a list of the Platform instances supported by the provider. In this vein we could rename the resource to "Provider" and simply state "this is a list of the Platform instances supplied by the provider".
Obviously, supporting multiple, incompatible implementations of CAMP is *one* reason for a provider to support multiple Platform instances, but there could be others. For example, a provider might have different service levels (e.g. silver, gold, and platinum) with different price points, each of which might be implemented as a separate Platform instance. Alternatively, a provider might choose to support different geographic regions (e.g. Europe, North America, Asia) with different Platform instances. The point is that the CAMP spec doesn't have to (and ideally shouldn't) tell a provider *why* they should create separate Platform instances, but it does need to support the discovery of those instances.
was (Author: gilbert.pilz):
In addition to listing "backwardCompatibleSpecificationVersions" and "backwardCompatibleImplementationVersions" to the Platform resource, I'd also like the TC to consider changing the nature of the Versions resource. Rather than explicitly tying what is essentially a list of links to Platform resources to the spec and implementation versions support by those Platforms - we should just call it what it is, a list of the Platform instances supported by the provider. In this vein we could rename the resource to "Provider" and simply state "this is a list of the Platform instances supplied by the provider".
Obviously, supporting multiple, incompatible implementations of CAMP is *one* reason for a provider to support multiple Platform instances, but there could be others. For example, a provider might have different service levels (e.g. silver, gold, and platinum) with different price points, each of which might be implemented as a separate Platform instance. Alternatively, a provider might choose to support different geographic regions (e.g. Europe, North America, Asia) with different Platform instances. The point is that the CAMP spec doesn't have to (and ideally shouldn't) tell a provider *why* they should create separate Platform instances, but it does need to support the discovery of those instances.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]