Date

30 April 2009

In Attendance

• Paul Biondich
• Mike Seaton
• Ben Wolfe
• Justin Miranda
• Burke Mamlin

Agenda

• Do we want to follow Carl Fogel's advice and try to avoid having development discussions within our issue tracker? Discuss (1) whether it matters to us or not and (2) if it does matter, how we manage it going forward.
• Review progress on getting synch into trunk
• Discuss research on module framework migration to OSGI.
• Review active lists ideas

Minutes

Design Discussions in Tickets

• Karl Fogel warns against this in his Open Source Bible
• Burke points out the specific ticket referenced above related to web services, and how a fairly detailed design discussion has been occurring without his knowledge
• Decent consensus among the team that this is a bad trend
• Do we have some way of managing it?
• Peer review and pointing out when this happens directly on the mailing list
• Reflecting Trac changes to the developer's list were discussed, and were thought to add too much traffic
• We will add conversation around the conventions to prevent this from happening going forward

Migration of Sync into Broad Use

• Initial goal is to extricate UUIDs from sync branch, and then port the rest of sync into a module
• Some concern around sync's move to a module in that if the module doesn't start gracefully, then data will be lost
• Perhaps putting additional support around modules to ensure that the sync module starts might be important
• Discussed some distinctions between "required" modules (system can't start unless module starts correctly), and all other modules (system should notify when module doesn't start correctly)
• Ticket #1453 and #1454 were written to address these issues
• Some design administrivia around UUID reconsiderations, including removing the notion of "changeable"
• UUID changes will be available in 1.5
• Once UUID changes are in place, Darius, Maros, and Ben will work to port sync code into a module.
• Target for Sync module's release is post 1.5

1.5 Alpha Release

• Will happen next week once UUID changes are complete
• Code review around UUIDs will happen on Monday
• Major other features include moving old reporting into module, complex_obs, new startup features, location hierarchy, etc...
• Here is a link to more details...

OSGi-ification of Module Engine

• OSGi within a webapp is possible with something like the Equinox servlet bridge. This just require us to package the core OpenMRS WAR as a bunch of OSGi bundles.
• This will require some more research as we begin to explore OSGi over the next few months. Spring has OSGi-ified most of its components and has its own Dynamic Module server that could also be used to deploy an OpenMRS OSGi platform.
• Justin likes the Spring approach because it supports most of the OSGi R4 implementations like Equinox, Knopflerfish, and Felix – so we'll have some choices when we're ready.

Active Lists

• Background on brainstorming is here...
• Burke reviewed the large details (API design, data model implications)
• This is a Summer of Code project
• Open Questions
  1. Does this design make sense?

     Yes. Burke will widen this conversation to the developer's list as well.

  2. What implications does this have to other conventions?

     This is another way in which people can store data that's longitudinal in nature. Programs and workflows are the other. We need to carefully consider additions that create design "options" that might not be congruent between implementations. We will need to have a longitudinal data "summit" sooner than later.

  3. Should this work be done in a module or in a branch?

     Justin and Mike concerned about the cartesian product that might emerge when convenience methods are made available under the patient service. Burke is concerned about the implications when we've organized things so well that it renders the API less user-friendly as a result. The todo is to discuss the API implications of Active Lists on the developer's list and that will allow branch vs. module to be answered.

  4. Where does this feature sit on the roadmap?

     At this point, this would be a candidate for 1.7