[OASIS Issue Tracker] Commented: (CAMP-163) Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36793#action_36793 ] 

Alex Heneveld commented on CAMP-163:
------------------------------------

Devdatta your point about this increases model interpreter complexity is well taken.  However I think that is a small price to pay (and it's not *that* much more complex is it?) for a spec which is easier for plan readers and writers.

Particularly when app topologies become large, the author's being able to choose when something is nested and when things are top-level can make plans clearer.

I would like to put together some bigger examples into a primer to illustrate this, helping people understand when/why some things are preferred.  We'd welcome your involvement Devdatta when we come to do that.



> Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
> --------------------------------------------------------------------------------
>
>                 Key: CAMP-163
>                 URL: http://tools.oasis-open.org/issues/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 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