Do we want to localize all the assets to a common directory or continue to hunt all over LibreEHR for them? @ken @sam @tony
I am of mixed opinions about this. Moving the deck chairs around is not necessarily a way to get new users or devs. It may be better to focus on new, visible value-add or more modularization first, but arguments can be made both ways.
Adding @aethelwulffe for comment.
My personal opinion is not one that I am comfortable with, since my own history of thinking in terms of MOD [modification] and ADD-ON [library/module] are bent towards a combination of things that are done at time of re-compile (MOD), or are consumed by an add-on system by the engine (libraries) that are called by changes to the user accessible config files/system. This can be quite similar to the closest corollary in web-scripting I have experience with, which is where there is an add-on module system, but the modules themselves very often have alterations to the base code files that they make. My experience in this comes from things like bulletin boards, accounting software, CMS and the like. Modules are generally clean and save, but mods have to be carefully replayed on top of a clean base install, and combinations of mods must be very carefully tested before deployment. Automated scripts for mods often have things go wrong. So to my thinking: Modules are modules, and have established hooks that do not have to be customized for the module to integrate. It also does not interfere with the base code…at all. That means that the hooks don’t really ever replace the base code by inclusion or exclusion, so the base code can continue to change without the modules constantly having to play catch-up. Vendor assets that are hooked into the base code are really modifications. I feel that if there is a vendor-modified (meaning custom code) thing that does not have an official hook in the mod system as a separate mini-application, then the calling script file should have nothing more than a “run that other thing instead of this, exit/die”. I understand that due to my lack of knowledge of how to do these things without a true separate front and back end, and no real module and integration system, my opinions lack validity. I do have confident feelings about a couple of things though:
- It would do no harm to shift these deck chairs around.
- There are those individuals that would be attracted to an improvement in the fung shui that this represents.
- It may help even those folks that don’t see the value of having a neat deck, as it may help keep them from stumbling and falling overboard.
- There is a matter of pride and not having your deck in a total state of mess. Sometimes the beer tastes better when everything is neat looking.
- Finally, in the act of organizing the deck chairs, you may well discover that a few of them are in need of repair. You might find one that you would rather be sitting in as your favorite…and you may realize that you have too many or don’t have cup-holders enough for the ones you do want.
In closing, there are those of us that have no idea on how or what to do to provide a module, and have little value to add. We are, however, capable of doing some grunt cleaning work like organizing and evaluating deck chairs.
I don’t think this is useful at this time. Moving things around will break references to those things and since we have no regression testing model, this will be very risky. I don’t think the OpenEMR model is too bad, most things are already in known locations. I think that pruning out files that are no longer in use and consolidating might be useful, but moving assets to a “vendor” directory doesn’t really accomplish anything. The way I see it, you specify dependencies, and they would get pulled into the vendor directory via some build process, but this isn’t really the case here. Until we have some standard method of managing script dependencies, I don’t see a point in moving things around.
To me, I see little rhyme or reason to the directory structure. I also don’t see a map for new developers to figure out all those “known” locations. I do know that if it isn’t done early, it will not get done later. I am a grumpy old sob that has unsuccessfully challenged that idea of a place for everything and everything in it’s place for years…and paid the taxes for doing so. This stuff DOES have an overhead that debits the future into infinity.
Why does the code base have multiples of everything? Same reason as why there are fifteen cigarette lighters under the truck seat. Couldn’t find em.
…said my piece.