DMP Photo Booth: A Question of Configuration
Over the past few weeks, I’ve been busy laying the ground work for DMP Photo Booth. Creating NetBeans projects, shelling out the module libraries, creating unit tests, making sure everything compiles, making sure my API is sane… While doing all of this, it occurred to me that I need to provide a standardized way to configure modules. After all, one size not fitting all is the reason I went down this road in the first place.
I’ve decided that each module needs to have three functions added:
char * dmp_**_get_config_location(char * to_fill, size_t size); int dmp_**_edit_config(); int dmp_**_load_config();
For each of these, the ** stands for the module prefix, so tm for the trigger module, cm for the camera module, and pm for the printer module.
This function returns the path to the module’s config file. Logically, this file would be located in the same folder as the module, but I don’t want to make the rules if I don’t have to. This function takes an allocated char *, and a size_t that describes the length of said string, and fills the string with/returns the location of the module config. It is the caller’s responsibility to free this string afterward.
This function instructs the module to edit it’s config. It is up to the module how they want to handle this, the core will not impose any requirements on this. The module could launch vi to edit a flat file, the module could launch a fancy editing interface, the module could open a web page, the module could just display the output of
get_config_location in a popup. If the module doesn’t require configuration, it can just return DMP_PB_SUCCESS and be done with it if that’s what it wants.
This function instructs the module to reload it’s configuration. This idea is that after this function is called, the old config is purged and replaced with the new config.
Nobody likes a constantly changing API. That said, I can’t promise at this point that it will not change. Things are still fluid, and that makes right now the best time to make changes. Better to refactor early than to be stuck with a mistake in the name of a concrete API.