While module integration has been an ongoing topic on our issue threads
I want to continue on the developer forum as we start implementing/integrating using lessons we’ve learned and trying to consolidate to a single point of discussion.
First i’d like to clarify what my opinion of a module and a plugin are.
- A module should be loosely integrated with core. Meaning, the module would be developed as if it could mostly stand on its own as if a client to openemr. The module can be reliant on core however, core can not be reliant on module.
I know this brings up difficulties with UI interactions so, openemr will need to provide a mechanism for these interactions. These mechanisms are vague currently but, if one reads the issue threads you can get a sense of where it is going.
- Plugin/Addon could and most likely will be, as tightly/loosely integrated with core as needed. These are current/new features that to start, would be spun off current openemr core. Thus getting us closer to a modular openemr.
@mdsupport has been kind enough to give us an example of this in this example PR OeModule by mdsupport · Pull Request #3076 · openemr/openemr · GitHub
An added benefit to doing this will be moving away from managing features from globals and placing that responsibility with module setup on install. Of course, openemr will need to provide the arbitration/dispatching to support but, concepts have been and continue to be discussed.
Currently most emphasis has been using composer for installs. We recently implemented openemr root project version in composer where version conflict arbitration can be setup on module installs. Soon I will be changing our openemr release tagging to the more appropriate semantic versioning. Eventually i’d like to see a complete openemr install from composer. We have the packagist account so, doable.
Module upgrades/uninstall still need to be worked out but most likely will be left to module developer to provide those kind of actions.
So at this point in the project, I see my job as trying to tie some of this together and get integrated into codebase. This way the opportunity for others to use and contribute will be easier.
- write interface classes for fax and sms. Using these we can implement interfaces to halifax or faxsms module. Keeping in mind to allow fax and/or sms for those that might want just one.
- split up faxsms module to support interface. Currently I arbitrate vendors in module dispatcher but may break that out.
- pull halifax to plugin
- implement the module setup logic to zend installer as @mdsupport purposes with some additions
- possibly creating some traits we can share with modules/plugins.
And lastly, umm remember how to do all of that.
Hopefully, once done, it can firm up a way forward.