Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Talk:COSMOS Design 208274"

(Mark's Comments)
(Mark's Comments)
Line 5: Line 5:
 
<ol>
 
<ol>
 
<li>
 
<li>
 +
Re: [[COSMOS_Design_208274#Creating_a_new_Data_Manager_project|Creating_a_new_Data_Manager_project]]<br>
 
<font color="blue">
 
<font color="blue">
 
<mdw>
 
<mdw>
Line 17: Line 18:
  
 
<li>
 
<li>
[[COSMOS_Design_208274#Generating_EPRs|Generating EPRs]]
+
Re: [[COSMOS_Design_208274#Generating_EPRs|Generating EPRs]]<br>
 
<font color="blue">
 
<font color="blue">
 
<mdw>
 
<mdw>

Revision as of 13:52, 25 January 2008

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 whiteman.us.ibm.com 12:38, 25 January 2008 (EST)
  2. 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 whiteman.us.ibm.com 12:50, 25 January 2008 (EST)

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.


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