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-62) JSON arrays of Links are more constrained than the underlying implementation

     [ http://tools.oasis-open.org/issues/browse/CAMP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gilbert Pilz updated CAMP-62:

    Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51359/camp-spec-v1.1-wd29-issue62.doc  (was: High level proposal: replace Link arrays with Link maps of some kind.)

Added link to concrete proposal. This proposal "resolves" this issue by adding some pious advice about how Providers should preserve the order of elements in an array across HTTP requests.

> JSON arrays of Links are more constrained than the underlying implementation
> ----------------------------------------------------------------------------
>                 Key: CAMP-62
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-62
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Adrian Otto
> Most CAMP resources are related to other CAMP resources in some way. We represent this relationship with the Link type. In cases where a CAMP resource may link to more than one other CAMP resource of the same type (e.g. Application Component Templates may link to one or more Platform Component Templates) we serialize the collection of Link instances using a JSON array. However, the order of elements within a JSON array is significant whereas the order of Links in a CAMP resource is not. We have picked a serialization method (the JSON array) that is more constrained than the semantics of the underlying implementation (a collection of references to other resources).
> The downside of this is that implementers of CAMP will have to write code whose only purpose is to preserve the ordering of the links/relationships between resource even though CAMP doesn't actually care about that ordering.
> For example, the code that implements the JSON Patch support for Link arrays must make sure to preserve whatever order is initially presented to the user. If a user does a GET on an ACT and receives the following:
> {
>    "type": "applicationComponentTemplate",
>    "uri": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/ApplicationComponentTemplate/17";,
>    "name": "sample",
>    "created": "2013-04-13T18:33Z",
>    "platformComponentTemplates": [   {
>       "href": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/PlatformComponentTemplate/0";,
>       "targetName": "Apache Tomcat 7.0.29"
>    },
>    {
>        "href": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/PlatformComponentTemplate/1";,
>        "targetName": "MySQL Server 5.5.21"
>     }
>   ]
> }
> then later sends the following PATCH request:
> [
>   { "op": "replace", "path": "/platformComponentTemplates/1", "value":  '{"href": "http://....}' }
> ]
> the CAMP implementation had *better* replace the link to the database and *not* the link to the appserver!
> It's likely that this JSON Patch example is just the canary in the coal mine. I anticipate many pesky coding problems due to the mismatch between the underlying semantics and the serialization construct that we have chosen.

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]