Feature request: decouple pulse from data directory
Currently, Pulse is tightly coupled with its data directory, such that it is difficult to provide external inputs (e.g., a patient from a source not in the data directory). As a library, Pulse would ideally give an application complete freedom to provide these files however it wants. At the same time, it is convenient for Pulse to provide built-in defaults.
For example, consider specifying a patient file to load (this example in Java):
SEPatientConfiguration pc = new SEPatientConfiguration();
pc.setDataRootDir("path/to/datadir");
pc.setPatientFile("patientfile.json");
First, it is strange that the path to the data directory needs to be provided to the patient configuration -- this seems like something that should be associated with the Pulse Engine itself as opposed to a specific patient. Perhaps similar to how the native library directory can be specified.
Second, Pulse assumes that patientfile.json
is in a patients
subdirectory under the data directory. This is not obvious, as seems like an unnecessary restriction -- the application should be able to provide the absolute path to any patient file it wants, and if a relative path is provided, it should be relative to the current working directory.
Of course, for an easy out-of-the-box experience, it's convenient to be able to assume that everything is relative to a common data directory. So what I suggest is a search scheme:
- The data directory is specified separately at the engine level. Only the patient file is specified as part of
SEPatientConfiguration
. - If the patient file is absolute, load it directly from the specified location.
- If the patient file is relative, try to load it relative to the current working directory.
- If that doesn't work, try loading it relative to the data directory.
- If that doesn't work, try loading it relative to datadirectory/patients. (This is for backwards compatibility.)
This seems to provide a lot of flexibility and has more intuitive behavior (to me, at least) while still ensuring that nearly all existing code will still work. (A possible exception is if there happens to be a patient file with the same name on one of the other paths that is checked.)
If you wanted to take this to the next level, you could allow the user to specify additional search paths.
Patients are not the only issue -- environments, substances, etc. should all behave the same way, in allowing the application to specify where to find them and falling back to the existing behavior as needed. This allows, e.g., the application to add/replace specific files while still using the default data directory for everything else.