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-5) Suggest to simplify {Application,Platform} Component {Requirements,Capability}


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

Tobias Kunze  commented on CAMP-5:
----------------------------------

Like I commented on CAMP-29, I wonder whether it is worth simplifying the "inheritance" at the expense of utility. Requirements are used differently than Capabilities. I don't see anything wrong with

    class A
        ...

    class B < A

    class C < A

Au contraire, I can now code

    if class == B

instead of

    if class.__type__ == "B"

The reason why I suggested this issue is not only because the "ApplicationComponent" part in ApplicationComponentRequirement (and similar) is truly superfluous (the Requirement is exclusively pointed to only by that ApplicationComponent, no other) but also because, as far as Requirement/Capability matching  (i.e. dependency resolution) is concerned, there is no difference in behavior, i.e. the various Requirements and Capabilities are matched irrespective of whether they are pointed to by (linked off) an ApplicationComponent or a PlatformComponent or an ExternalComponent. In that sense, it is compatible with my "horse" analogy here: https://tools.oasis-open.org/issues/browse/CAMP-29?focusedCommentId=31735&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_31735

> Suggest to simplify {Application,Platform} Component {Requirements,Capability}
> ------------------------------------------------------------------------------
>
>                 Key: CAMP-5
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-5
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Anish Karmarkar
>
> Instead of talking about
>   1.  Application Component Requirement
>   2.  Application Component Capability
>   3.  Platform Component Requirement
>   4.  Platform Component Capability
> I suggest we simplify these terms to just Capability and Requirement. Rationale is that, since these structures are all likely to be very unique, we should actually be talking about (and introducing types for) "Application Component X Requirement" etc., which would be overkill. Hence, my suggestion to use only one simple type for each.
> However, as Mark pointed out, there are differences between these types on the Application and Platform side regarding whether or not they are required, etc. My sense is that we'd stand to gain more from simplification, though.
> [This issues was raised by Tobias and was drupal issue # 1032]

-- 
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]