[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=35208#action_35208 ]
Gilbert Pilz commented on CAMP-44:
----------------------------------
Alex,
Your last comment is the most crucial one for this issue as far as I am concerned.
I may have overstated things somewhat when I said that adding an extension attribute to an existing resource requires you to create a new resource type. However, I'm not sure how practical it is to say that every Component resource has "type": "component" and whatever additional attributes it needs to express its unique characteristics. Suppose I have 6 kinds of components in my platform. Foo components have 4 additional attributes, Baz components have have 6 additional attributes, Zoup components have 3 additional attributes, etc. My TypeDefinition for the Component resource has 20 extension attributes all of which are marked as "required: false - since you can't count on any of them being there without knowing which kind of component you are working with, etc. This seems like a bit of a mess as far as writing client code that understands anything about these component types.
We could get fancy and define some sort of collection of attributes that could be mixed in to any resource that declared (via its TypeDefinition) that it supported that collection - but I'm wary of introducing that level of complexity. I might concede the necessity of doing something like this if the CAMP TC were in the business of defining things like "database component", "message queue component", etc. (see CAMP-26) but, so far, the TC seems to be steering away from doing this.
> 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]