Skip to main content
Jump to: navigation, search

Talk:COSMOS Design 208274

This is the talk page for COSMOS Design 208274.

Mark's Comments

  1. Re: Creating a new Data Manager project
    <mdw> Since CMDBf is a primary use case, I think it would be good to call this out directly in the design of the user interface. Here, we could have the "Systems Management Menu" and underneath it, add "CMDBf Management Data Repository" and "Custom Data Manager". This should be an extension point that people can register under. This would be consistent with the COSMOS programming model in that CMDBf APIs are simply "convenience" APIs on top of data managers. I may want to be able to register my own kind of APIs. </mdw>
    We do call this out, in the "project type" group on page 1 of the project creation wizard. We were thinking this would be more flexible than requiring that the choice be made in the tree where you select what kind of project to create. I'd be interested in hearing more specifics on your extension point thoughts. David 12:38, 25 January 2008 (EST)
  2. Re: Create Data Manager Project Wizard
    <mdw> I think we should break this down into two parts and base this on the metadata that is defined in the CMDBf spec. For metadata that would apply to all data managers, we have something like this screen. When you are defining an MDR, we add a page for MDR specific metadata, e.g. depth level. Likewise, this should be an extension point that we register with. </mdw>
    OK, I added some text along those lines. Question: since this is an extension point, I'm guessing the project type choice will need to be a drop down list rather than a radio button? Should other project types be added per extension points? David 13:16, 25 January 2008 (EST)
  3. Re: Create Data Manager Project Wizard
    <mdw> I don't think "Tomcat" is an environment. I think we would have J2EE or OSGi. I'm not sure if we even have the OSGi requirement any longer and I'd be willing to simplify if we could. We should check with the SDD folks as they might be the ones that will need to use OSGi. It't not clear what the "Create JUnit" stuff would do. I'd rather see a generic "test harness" for CMDBf if there was a way to swing it. The test harness should be a separate ER and tied to pluggable resource model. </mdw>

    We call it a "deployment target" not an "environment". I guess your general comment is Tomcat is too specific of a term here. I updated the UI accordingly. The "Create JUnit" option was just to specify whether "Creates org.eclipse.cosmos.*mdrname.mdr.test junit project" and "Creates Junit test *" as described in the list of wizard responsibilities. It agree it's strange to have that though since other project wizards don't offer that an option, and JUnits are not specific to data manager projects. I removed it. David 13:16, 25 January 2008 (EST)
  4. Re: Generating EPRs
    <mdw> The issue that I see here is that the EPRs will change when you move from dev -> test -> qa -> production. Specifying it here I think is not the right thing to do. </mdw>
    This is just to specify the initial content of the EPRs, since coding the XML by hand is tedious and error prone. Clearly you would need to tweak this as you go through development. We could provide a project property page, like the one described in the next section, for you to change those values and re-generate the EPRs. This is much like what is found in the WSDM toolkit. David 12:50, 25 January 2008 (EST)
  5. I'd like to see integration with things like "Run on server" where the MDR is essentially opened up. Integration with a test client/harness at that point, e.g. embedding part of the cosmos UI may also be a good thing. Could also include some "pre-canned" queries, e.g. "Show all record types" or something like that.
  6. What about the notion of cheat sheets? Any thought of using them here?
  7. What about linkages into the resource model and Ali's model mapper ER?

Ali's Comments

Awesome job on the first iteration of the design!

1) Not clear on what you mean by the following two points under "Development environment":

  • Developers will create extensions to the COSMOS framework in the Eclipse workbench environment.
  • Examples and documentation on how to extend the COSMOS framework will be provided, integrated with the Eclipse help system.

I'm assuming this section is to describe the development environment required for end users to create data managers. Extension points don't play a role in this section. Extensions are only used by adopters intending to extend the wizard to provide additional functionalities when creating a data manager. Extension points deserve an entire section of their own.

2) A typical data manager project is composed of three plug-ins:

server plug-in // Contains the server code
common plug-in // Contains code shared between the server/client plug-in
client plug-in // Contains client code

According to the description of "Create Data Manager Project Wizard", only the server plug-in is created. We need to also consider adopters intending to write their own client code.

3) Depending on how extensible we intend to make the toolkit, the layout of the "New Data Manager Project" mock-up will need to change. For example, the deployment target and data manager type are extensible entities that deserve a wizard page of their own. A deployment target may also require configuration settings (e.g. location of a tomcat instance). I suggest making the data manager type and deployment environment the second and third page of the wizard respectively.

We also need a series of extension points that will allow adopters to define data manager types, deployment types, the association between a data manager and deployment types, and configuration settings that need to appear as wizard pages.

Another question on my mind is whether a deployment target is required as part of creating the project. If not, then there is no need to prompt the user for a deployment target in the "Create Data Manager" wizard. It may only make sense to prompt when the user exports/deploys the data manager.

4) Under "Generating EPRs" section, it sounds as if the wizard page is a nice-to-have. This is a necessity for the toolkit. There should absolutely be no need for users to modify text files.
Good point. I reworded it accordingly David 12:54, 25 January 2008 (EST)

5) As mentioned before, we should combine the configuration and the domainEPR xml file into one file. Is there a need to have two separate files? Making an editor association with just one file will make things easier. From the mock-up, it appears you're combining the content of the two files into one page that you intend to display in the manifest editor. This will introduce unnecessary complications when the user edits the page.

6) The design document needs to elaborate on:

a) The export/deployment operation (what will the wizards look like)
b) The extra wizard pages that will appear for specialized data managers (i.e. MDR/federating CMDB)

Back to the top