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-44) Clarify resource type issues and API


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

Alex Heneveld commented on CAMP-44:
-----------------------------------

Gil, do you think we could do multiple inheritance instead?

My reasoning is that, as CAMP is an interface, all the "types" we talk about are interfaces -- the implementations are hidden from the user.  Most arguments against multiple inheritance apply to implementations so it feels safe.

Concretely it would be useful in situations where I care about surfacing inheritance, there might be multiple inheritance hierarchies I am interested in -- such as to indicate the presence of additional attributes.

OTOH with capabilities/requirements/characteristics we could probably do without any inheritance/extension in our types.  All components declare their type as "component", and you look at capabilities to understand behaviour.  (I think you are mistaken when you say your resources MUST be of unique type because they contain unique extensions.  I believe a resource may include attributes in addition to those declared on its type, according to the spec as well as previous TC discussions.)

> Clarify resource  type issues and API
> -------------------------------------
>
>                 Key: CAMP-44
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-44
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Task
>          Components: Spec
>            Reporter: Alex Heneveld
>            Priority: Minor
>
> There were several key questions about types that have come up in today's F2F:
> What type hierarchy will we use?  Mark requests ability to define e.g. MyGreatDatabase which extends Database.  (We could also have multiple inheritance / interface / etc.)
> How do we explore the type hierarchy?  (The apidoc suggestion in CAMP-1 could come in here.)
> And do we permit dynamic attribute extensions -- e.g. a resource instance has values for other attributes not on its type?  (Yes please!)

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