Questions for informing work on Kepler configurability

General questions about Kepler configurability

1. What is the list of general things that will be configurable in Kepler 2.0?  (See below for examples.)
2. In what various ways will configuration be represented physically?  (Files, command-line arguments, files specified by command-line arguments, Java properties, environment variables, etc.)
3. What kinds of configuration can/should be provided via files in modules?
4. What kinds of configuration can/should be provided to Kepler from the command line?  (E.g., how much memory to assign to the JVM, whether to run headless, overrides to configuration values specified in files, etc?)
5. What tradeoffs are to be considered when deciding whether to read particular configuration items from the command-line vs a file?  (E.g., configuration files are more convenient for large amounts of configuration information, whereas command-line aguments are easier to change between runs, especially within a script.)
6. Can/should any configuration be provided from Java properties or OS environment variables?
7. Will configuration information be accessible uniformly from application code, i.e. independently of how and where it is stored?  
8. Should it generally be possible to (transparently) override configuration stored in files using command line configuration information?
9. Can users set, save, and load configuration information?  What kinds?  (Does the current list of active modules count as configuration? How about the language used in the menus and other GUI widgets?)
10. Can users save distinct sets of customized configuration and specify which custom configuration set to use at run time? (This could, e.g., allow users conveniently to switch between different sets of active modules along with custom GUI layouts for each set).
11. Can read or write access to configuration be controlled by other configuration? (E.g., for security.)
12. Will there be a way for users to restore the default values on particular items, or sets of items?
13. Will there be ways of referring to subsets of the entire configuration of Kepler?
14. Are we going to be enforcing naming conventions for configurable values?
15. Is there a distinction between 'central configuration' and 'module configuration'?
16. Will upgrading or patching modules ever be able to change existing configuration?  (What happens when an upgraded module no longer exposes a configurable item? When the default value for a configurable item changes between versions?)
17. Can configuration information be accessed from within actors or workflow parameters?  (Useful, e.g., for specifying locations of resources used by actors.)
18. How are we going to document configuration files?
19. How are we going to document the expected errors that will occur if configuration files are specified incorrectly?
20. Will there be a way to specify allowed values? Should there be validation and type checking?  (If not, how much Java code in each module might needs to be written to do the checking on a case-by-case basis? Could the methods used to access configuration values do the type-casting and type-checking work based on the name of the method used?).
21. How important is that configuration files be easy to (a) read, (b) write, and (c) understand by developers?  By scientists?  By scientist/developers?
22. Must configuration parameters and files be well-documented?  
23. What are the tradeoffs with respect to configuration file formats?
24. What things are going to be configured by the Kepler/CORE team? (Ideally? Pragmatically?)
25. What are the general guidelines for making something configurable? (Avoid recompliation if something needs to change, to provide overridable default behavior, to lower the burden on the user, to help deploy the system in diverse environments, etc)
26. From a workflow point of view, when is information considered 'input data', and when is it 'configuration'?
27. What does configuration represent conceptually?  (Resources required by modules, look and feel of the system, user preferences, defaults gui layouts...)