Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:COSMOS Design 208584"
| Line 1: | Line 1: | ||
| − | + | == '''Comments from Valentina Popescu:''' == | |
| − | + | ||
| − | ==Comments from Valentina Popescu:== | + | |
* I am not sure if this is a new change for 1.0 but I see that the query service and registration service is not required for an MDR. Note the MAY in the sections copied from 1.0, below: | * I am not sure if this is a new change for 1.0 but I see that the query service and registration service is not required for an MDR. Note the MAY in the sections copied from 1.0, below: | ||
Revision as of 16:02, 5 December 2007
Comments from Valentina Popescu:
- I am not sure if this is a new change for 1.0 but I see that the query service and registration service is not required for an MDR. Note the MAY in the sections copied from 1.0, below:
Query Service. Both MDRs and Federating CMDBs may implement the Query service to make data available to Clients. Queries may select and return items, relationships, and/or graphs containing items and relationships. Registration Service. A Federating CMDB may implement the Registration Service. An MDR may call the Registration Service to register data that it has available for federation. A Federating CMDB declares the data types that its Registration service supports. An MDR maps its data to the supported types.
That means that our MDR framework MUST allow MDR implementations without a query service defined (same for registration service). The spec says: A Federating CMDB must use one or the other mode and MAY use both.
So a federating MDR can choose to use pull or push but must choose one or the other. It is not clear to me what happens when an MDR does not define a query service and the federating CMDB decides to use pull. It is also not clear from the spec what is normative (MAY uppercase) and what is not. I’ll send a note to the spec author and ask for clarification.
- Re: the note to reviewers regarding section 6 of the CMDBf 1.0 spec, I propose to open a different request (enhancement) to deal with this new feature. The main reason is that the current enhancement deals with moving COSMOS CMDBf code from 0.9 to 1.0. This feature is optional (compliant implementations are not required to support it); we should aim to add this type of support to our own implementation, though this task is not a blocker for porting to 1.0. Note that this is also not trivial to implement.
- propose breaking up the CMDBf definition into the following two entries:
| CMDBf | CMDB Federation Specification |
| Federating CMDB | As defined by the CMDBf spec, a CMDB that federates data from multiple MDRs |
- add to end of MDR definition "as defined by CMDBf"
- add to end of SML definition "as defined by ITIL"
- add to the beginning of 4 of the last 5 terms (except "CMDBf query") the word "COSMOS"
- change cmdbf.query modules definition to start with "The modules provided by COSMOS CMDBf framework"
Response to Valentina Popescu comments:
- Good thoughts ... it will be interesting to see what he says
- Agree, we should make it a separate work item
- will make this change, thanks
- will make this change, thanks
- will make this change, thanks
- Instead of adding COSMOS to all those term names, I'd prefer to add a disclaimer such as this: "These definitions are not meant to be general definitions of these terms, but rather refer to how the terms are used within this design document as applied to COSMOS." It seems redundant in some of these cases to include the word "COSMOS" in the term.
- will make this change, thanks