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

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

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

Alex Heneveld commented on CAMP-169:
------------------------------------

Devdatta's point that this increases model interpreter complexity is correct. 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 to express things naturally.

I think of these plans as architecture diagrams:  how you lay out the diagram depends on what the primary and most important relationships are.  There may be multiple ways to draw a diagram which are equivalent -- a machine won't care, but to a human some ways of presenting it will be easier to read.  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. 

What we do need are bigger examples to illustrate this.  Hence the TC's decision to make this a primer issue.  Contributions welcome.  I'd rather we concentrated on this.  If those examples suggest e.g. that shared services must always be listed in a separate place from the artifacts which depend on them, then we could revisit this proposed spec change, but my experience makes me think that won't be the case and I'm not in favour of changing the spec hypothetically.

> 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: Possibe Work Products
>            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.1.1#6155)