Hi All,
We think we’re happy with that is built in the allergyapi module, right? (Though we still need to work on making it possible to update the allergy list via REST.)
Can we make it a priority in the next OpenMRS platform release to remove the old 1.7-era allergy code, and incorporate the allergyapi code?
That sounds right to me, this reminds me of the calculation and event module that were developed with intentions of moving them to core too and it is the reason they have package names that don’t contain ‘module’. I believe they have been around for a while and proven, it would be nice to move them too.
What are the cons of moving towards a model where core/platform is mostly
bootstrapping and a few other things like the module framework? Then all
the often changing clinical functionality being in form of modules?
In the past, i have seen people do things in modules, because they can be
released immediately. Which has not been the same case with core/platform.
May be we just need to improve our platform release strategy??? 
(Personally I think that since the calculation and event modules have not gotten a lot of uptake, we should hold off on incorporating them into core.)
There are at least two motivations for migrating commonly used (and stable) code to core:
We want them (resources/services) to be used/visible to all other modules.
Adding modules is not without a cost (e.g., performance, perhaps memory?, all modules must be restarted when any one is started or stopped, etc.)
I agree we’d like to keep core lean, but we need some improvements to the module framework (e.g., a module service with explicit classpath control and without memory leaks… and maybe a clean separation in the UI between “system” and “user-installed” modules) before we get overly module-happy with core functionality.
According to https://ci.openmrs.org/sonar/ OpenMRS Core is already very lean, just 100K lines of Java code. I don’t see how is going to hurt to add some modules to it. It makes not only deployment easier but development as well.
Makes lots of sense. Ok then let us improve our release strategy for the
platform/core.
I would just point out that core is always going to have a too-slow release process and roadmap for the needs of fast-moving implementations, and this is really by design.
I think that the new Allergy API is a great example of something developed in a module so it could be released quickly, and as this implementation is vetted (via the module) we can then add this functionality to core. (Aside: the core primitives to store clinical data really do belong in the core. E.g. as devs start experimenting with decision support functionality, and order entry, it helps if those devs can at least have a common representation of “are they allergic to X.”)
The event module is also a very good example of something. When we were building it, we thought it would be fundamental and transformative. But since the 1.0 release in 2012, I know of virtually no actual usage of this module. So, maybe it’s good that we didn’t restructure all of openmrs-core to support this approach. Or perhaps people will adopt it widely soon. 
According to https://wiki.openmrs.org/display/docs/Event+Module it looks like a message broker that supports publish/subscribe model (not the peer-to-peer one). It could be useful for instance to run reports asynchronously and to notify the outcome. Or by the Sync module (but IIRC it already uses Apache ActiveMQ).