Date

30 April 2009

In Attendance

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

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

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

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 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.

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?
2. What implications does this have to other conventions?
3. Should this work be done in a module or in a branch?
4. Where does this feature sit on the roadmap?