30 April 2009
- Paul Biondich
- Mike Seaton
- Ben Wolfe
- Justin Miranda
- Burke Mamlin
- 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
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.
- Background on brainstorming is here...
- Burke reviewed the large details (API design, data model implications)
- This is a Summer of Code project
- Open Questions
- Does this design make sense?
- What implications does this have to other conventions?
- Should this work be done in a module or in a branch?
- Where does this feature sit on the roadmap?