Meeting Notes -- 09 Apr 2003

When & Where

• Wednesday 09 Apr 2003 -- 2:00 to 3:15
• OSAF office in Belmont

Who attended

• Chao -- ChaoLam
• Katie -- KatieCappsParlante
• Brian -- BrianDouglasSkinner

Agenda going in

• Have Brian/Katie provide Chao with a high-level summary of the data model work.
• Talk about where the data model work should fit in on the product road map for release 0.2 and beyond.
• Talk about how to organize the data model work, and how to sequence it.

Highlights of what we talked about

• Overview questions:
  • What is the data model?
  • Why is it important?
  • What is its relationship to other parts of the design?
• Overview answers -- We need the data model in order to:
  • define what kinds of things get stored in the repository.
  • define what kinds of things are shown in views.
  • describe what types of data structures can be used in Chandler to describe new kinds of things.
  • describe what sorts of data and relationships can be represented in the data store, and transmitted via RAP, and expressed in Python objects, and manipulated in views.

• What are the dependencies between the data model and other parts of the design?
  • The data model has interdependencies with lots of different things, including RAP, the repository/datastore, the generic table view, and the different parcels like Calendar and Email.
  • The data model will need to be revised to reflect design decisions made in all these other things.
  • The data model raises design questions that will impact all these other things.

• In a sequence of development tasks, where should data model work be placed?
  • There isn't a good waterfall sequence. It doesn't make sense to schedule the data model work before or after other design tasks. Progress on the data model will need to happen in iterations with progress on all the interdependent parts of the design.
  • Issues will get raised by people working on each of the different parts, and we'll need some process for identifying interdependencies, exploring alternatives, signing off on particular solutions, and incorporating the solution into all of the different interdependent parts.

• What should OSAF's goals be for release 0.2, vis-a-vis the data model?
  • Proposed answer:
    • end-to-end data -- Have release 0.2 demonstrate end-to-end data handling. Have support for only some fairly basic level of data expressiveness, but for each aspect of that expressiveness, have it be handled consistently across all the parts of Chandler.
    • data model -- Have a strawman data model that describes Chandler data
    • generic view -- Have a generic view that can display (and edit) Chandler data
    • Python mapping -- Have a mapping to Python objects that can represent Chandler data
    • RAP -- Have RAP transport the Chandler data
    • repository -- Have a repository that can save and retrieve Chandler data

• What should OSAF's goals be for release 0.3 and beyond?
  • Proposed answer -- Extend end-to-end data handling to support:
    • support for queries
    • support for notifications
    • access control
    • synchronization/replication
    • deletion and garbage collection
    • versioning
    • undo
    • schema evolution
    • etc.

• Should the data model doc be included as part of the release 0.1 architecture documentation?
  • Nope, it hasn't been peer-reviewed and doesn't represent OSAF current thinking. But that might be a good goal for release 0.2.
  • For release 0.1, we might try to have just a simple place-holder -- like a note on the architecture diagram, and/or a short summary statement that notes that the data model needs to exist, and explains what it will be.

• Should some sort of terminology document be part of the release 0.1 documentation?
  • Nope, it's probably to early to commit to many terms.
  • It will probably take some time to sign off on a good initial set of terminology.
  • This would be something good to try to do for release 0.2.

Game plan coming out

• Brian
  • Will draft an Introduction section for the data model
    • What is the data model?
    • Why is it important?
    • What is its relationship to other parts of the design?
  • Will move the data model work from Jungle.BrianDouglasSkinner-DataModelOutline up into DataModelIssues, merging the material from the two places.
  • The current document has a long list of different data model topics, where lots of issues get raised. Brian will add a brief intro section that has just a short list of some of the most significant issues -- the issues that it's most important to address sooner rather than later.

• Chao
  • Will incorporate the data model work into the road map.
  • Will add a terminology document as a line item in the road map plan.

-- BrianDouglasSkinner - 09 Apr 2003