Talk:COSMOS Design 208274

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)