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: [OASIS Issue Tracker] Updated: (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:all-tabpanel ]

Gilbert Pilz updated CAMP-40:
-----------------------------

    Proposal: 
Array-based proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48267/camp-40-2013-02-14-array.doc

Map-based proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48268/camp-40-2013-02-14-map.doc

  was:
Array-based proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48262/camp-40-2013-02-14-array.doc

Map-based proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48264/camp-40-2013-02-14-map.doc


Adrian pointed out the my proposals were not factoring in the "implementationVersion". Although we don't do a good job at documenting its purpose, "implementationVersion" is there to allow a provider to support multiple implementations of the same CAMP version. You might do this, for example, if you are a provider that had implemented a bunch of extensions and, for whatever reason, you need to make breaking changes to some and/or all of those extensions - "CAMP 1.1 with my old extensions", "CAMP 1.1 with my new extensions".

I updated both proposals. In the proposal that uses an array of Links, I added another extension attribute to the Link type. Now every Link contains both the specificationVersion and the implementationVersion. In the proposal that uses Maps, I had to expand the Map of Links to be a "Map of a Map of Links". This sounds a lot more complicated than it is, but the top-level key corresponds to the specificationVersion and the second-level key corresponds to the implementationVersion - with the final value being a regular, non-extended Link. If you look at the example, it all makes sense.

> 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]