Difference between revisions of "Cosmos Architecture Meeting 19-June-08"

Revision as of 12:54, 19 June 2008

These are the minutes for the Architecture Meeting for 19/6/08.

Attendees

• Bill,
• Jimmy
• Hubert
• Martin
• David
• Paul
• Shrinivas
• Ali
• Jason
• Mark

Agenda

• i11 Status
  • iteration candidate No2
• Dojo Update
• COSMOS CMDBf Query to SQL Mapping
• Hubert/Bill: Iteration of the design of the CMDBf handler framework.
• Jason (SDD?)

Meeting Minutes

i11 Status

There are currently 4 bugs open on i11 that will be resolved for the Monday build

• 237478 jagmits@ca.ibm.com Need to change build script for org.eclipse.cosmos.dr.web...
• 237482 martin.simmonds@ca.com Tabular query graph response view does not show the insta...
• 237519 amehrega@ca.ibm.com Problem with displaying registration response when regist...
• 237104 hkyleung@ca.ibm.com Error when using configDemo.bat

The above bugs will be resolved by late afternoon.

Once the bugs are checked in we will freeze CVS.

Any new bugs will go through the approval process.

QA will do a full test pass on Monday.

Shrinivas comment-- Performance testing may be delayed

Dojo Update

• COSMOS will need to follow up with Janet and eclipse legal team to scan the stripped version of Dojo submitted in the ip entry
• COSMOS will persue this action before considering other avenues to resolve the ip issues.

Link to Dojo IP Zilla: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2026

• ipzilla entry lists the files that were striped from the Dojo distribution.

Design of the CMDBf handler framework

Bill -- we discussed previously that we will come up with a set of best practice related to this. I Updated the wiki page with the mapping and cmdbf terminology. Added database mapping terminology regarding how to build a MDR.

Paul -- We decided that creating code for this ER would be alot of work. We would check with CMDBf folks that we weren't treading on any toes. How are we handling best practices? Do we need to instantiate the doc somewhere?

Mark -- does this make sense to be in the developer guide?

Bill -- yes .. the chapter how to build an MDR section.

Hubert -- there's a few things that we can need to consider... The current documentation doesn't align well with the database mapping practice. Another place this work can show up is in the Aperi MDR. There's some descrepancy in what we write and what we do. Also in our our toolkit code generation. We make assumption that ppl would use the factory class. all they need to do is provide a factory for the handlers. -- instead of having abstract methods that we require ppl to implement default code

Mark - we should be consistent what we do. Revisit Aperi MDR work.

Bill -- Aperi is in line with the mapping work. There's two types of implementation... the relational data base style and the handler style. The tooling is generating the handler style.

Hubert -- we need to make sure that the Aperi implementations is doing what the mapping page is saying. I remember there's a few place that are different between the implementation and the mapping page.

Bill -- we need to look at those differences and open Bugs in i12 to resolve the differences

Mark - we should definitely put this information in the developer guide.

Hubert -- in the section where we write how to create a MDR... there's 2 approaches. which way do we recommend.

Mark -- There are some benefits to the handler framework and there's some benefits to use the advance mapping framework. We need to document the benefits.

Bill -- There's no one size that fits all.

Mark -- what do we do in the tooling piece. The tooling generate the handler style. We want to be consistent with the tooling. We should look at the impact of the best practices document that we create. There's a level support that we want to provide to our adopters. We don't want to promote tooling that does not support our best practice statement. We have some inconsistency with what our tooling does, what were doing with the Aperi MDR and what we document.

Agenda for next week in looking ahead

Paul -- One of the things is security. I revamped the security that we can go with tomorrow. I don't have any

detail requirements. I wonder whether IBM has any requirements in this space that we can discuss.

Mark -- At this point we are still engaging and still trying to define what the requirements may be.

Bill -- Firefox 3.0 is out. do we have a plan for QA to test with Firefox 3.0?.

Mark -- We can figure this out for next week.

Sheldon -- Want to talk about Reporting Capabilities we are planning for i12

Next Steps

3 work items (Hubert to create ERs for the following work)

• document best practices and put in the developers guide so that the sections flows well in the documentation
• make sure that the aperi implementation is aligned with the documentation
• the code generated by the tooling aligns with the documentation. Hubert will take the to do to find a more flexible

way to allow users to bypass the handler framework.

See what IBM Firefox 3.0 time line is for 3.0. (Sheldon)