[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (CAMP-163) Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
[ https://issues.oasis-open.org/browse/CAMP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Chapman updated CAMP-163: --------------------------------- Resolution: Close no action. The id in the inline version is optional, and ease of building a parser is secondary to ease of writing plans. From 12th March 2014: Motion: close CAMP-163 with no action and reply to commenter stating our rationale for this decision; m: AlexH, s:Tom Martin: should open a new issue against "primer" to explain this aspect of the Plan file Motion Carries was: Close no action. The id in the inline version is optional, and ease of building a parser is secondary to ease of writing plans. from 5th March 2014: Gil: moves we open 163, Tom 2nd. Gil: P1 (will need a new PR) no obj. Adopted. > Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013) > -------------------------------------------------------------------------------- > > Key: CAMP-163 > URL: https://issues.oasis-open.org/browse/CAMP-163 > Project: OASIS Cloud Application Management for Platforms (CAMP) TC > Issue Type: Bug > Components: SPEC PR2 > Reporter: Martin Chapman > > https://lists.oasis-open.org/archives/camp-comment/201402/msg00001.html > Hi Adrian, > Recently I got a chance to take a look at CAMP working draft 39 (dated February 3, 2014). > I was specifically looking to see how the issue filed here > https://tools.oasis-open.org/issues/browse/CAMP-153 > has been resolved. > Upon reading through the comments on the issue, I am not sure I agree to the > justification given to keep two different service specification formats. > If I understand the justification correctly, it is saying that > the 'in-line' format of service specification is useful for the use case when multiple artifacts *don't* > want to share services. In such situations, the required services can be specified > 'in-line' with each artifact, whereas, if multiple artifacts need to share a service (same instance of it) then such a > service specification should be defined in the services section. > I still think that one could achieve both these use cases by having a single > way of defining required services in a separate top-level services section. > Having two different formats will lead to model interpreter complexity > without providing significant gain. > If, however, the TC wants to keep two different formats then one suggestion that I would like to make > is to enforce the distinction through the specification. > Currently the 'in-line' format is still exactly same as the 'out-of-line' format, > the specification does not explicitly restrict/enforce when to use one over the other. > One way to enforce this would be to remove the 'id' field from the 'in-line' definition of a service. > That way, it won't even be possible to reference an in-line defined service from outside > the defining artifact's scope. (to be concrete: remove 'id' from being a child of 'fulfillment' node > on line 14 of page 31). > In case this is not an option then another suggestion would be to at least explicitly call out > in the specification the need for providing two different ways to specify services and to suggest when > one format should be used over the other. > Regards, > Devdatta -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]