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] Commented: (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:comment-tabpanel&focusedCommentId=33064#action_33064 ] 

Gilbert Pilz commented on CAMP-62:
----------------------------------

WD08 says the following in Section 6.9.2 (Updating with JSON Patch):

"Conformant CAMP servers must support the HTTP PATCH method in conjunction with the "application/json-patch" media type with the following, additional provisions with respect to the operations defined in section 4 of the JSON Patch specification [JSON Patch]:
•	CAMP servers must support the 'add', 'remove', and 'replace' operations.
•	CAMP servers may support the 'move', 'copy, and 'test' operations."

Meanwhile Section 5.9.5 lists the "Consumer-mutable" constraint on "platformComponentRequirements" as "true".

Taken together, this means that the current draft of the spec requires CAMP implementations to support the use of JSON Patch to change the elements in the "platformComponentRequirements" attribute of an ACT. We can change this, but we should be careful to make sure we change it for any/all Link arrays that are consumer-mutable.

> 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: Gilbert Pilz
>
> 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]