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] (CAMP-169) CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)

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

Martin Chapman  updated CAMP-169:

From 11th June 2014:

      Motion: Gil:  Moves to accept his proposal in JIRA as resolution for ISSUE-169.
      Alex seconds
      Resolved without objection

Incorporate the resolution in WD 42 (https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53302/camp-spec-v1.1-wd42.doc).

  was:Incorporate the resolution in WD 42 (https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53302/camp-spec-v1.1-wd42.doc).

> CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
> ---------------------------------------------------------------------------------------
>                 Key: CAMP-169
>                 URL: https://tools.oasis-open.org/issues/browse/CAMP-169
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Primer
>            Reporter: Martin Chapman 
>            Assignee: Gilbert Pilz
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]