I’m moving some conversation from the VUFIND-682 ticket to the list to avoid going too far off topic there. Just sharing some thoughts (and looking for input) related to VuFind’s configuration.
At this point, my biggest configuration-related concern is that too many low-level components of VuFind pull configurations directly from the \VuFind\Config\Reader. I would like to try, as much as possible, to move Reader calls closer to the surface and inject configurations down from the controller or service manager level (i.e. add a configuration parameter to constructors or add setConfig() methods). By reducing the proliferation of static Reader calls, we make it easier to change the nature of the configuration if we need to. Whether or not we make fundamental configuration changes, I think this type of refactoring makes the individual components more flexible and independent.
That being said, I'm not currently inclined to drastically change the current arrangement. While it has some disadvantages -- primarily its unwieldiness, I can't think of an alternative that greatly improves upon it.
My thoughts on various specific issues:
-- Format --
VuFind traditionally (and still) uses .ini files for configurations. Zend Framework 2 uses PHP-based configurations.
This seems to pose a conflict, but I think the distinction can be made that .ini files are for user-oriented configurations (i.e. how the application behaves) while .php files are for programmer-oriented configurations (i.e. how the application components interact with each other).
I don’t think that huge PHP arrays are as easy for a non-programmer to work with as the more familiar .ini format, and I don’t want to introduce further overhead for the casual user.
Some features of the SolrMarc import tool (i.e. change tracking and full text indexing) need to be able to read in VuFind configurations; the .ini format is a useful cross-platform standard. I wouldn’t want to try to parse PHP in Java or require the user to create redundant configurations.
I’m sure the .ini format offers a performance hit vs. pure PHP; however, this can probably be alleviated by caching if it is deemed significant.
-- Organization –
There is no question that some of the configuration files are huge and intimidating, and some of the settings aren’t necessarily in the most logical places (i.e. some Solr-specific and Summon-specific settings currently in config.ini might live more comfortable in searches.ini or Summon.ini).
However, given that things aren’t perfect, I still don’t see a huge benefit to moving them around. Changing configurations has a high cost in terms of forward migration and documentation maintenance but relatively small benefit – even if we make things a little more clear, they’re still going to be hard to find in the sea of configurations. It’s an inherent cost of having so many options. I would rather focus on making the documentation in the wiki clear and helpful – focusing on having clear, searchable documentation seems of greater benefit than self-documenting configurations, which are probably an impossibility.
Another factor worth considering is software-driven configuration. VuFind 2.0’s install process does a little bit of this, and perhaps it could be taken further to help point people toward important options they might want to try. I’m not enthusiastic about taking this too far, though – ultimately, it just becomes another thing to maintain, and encouraging people to rely on online configuration also encourages them to loosen security, which is not the best policy.
That came out a bit longer than I expected, but I think it covers the main points I’ve been thinking about. Feedback is always welcome.