The prevailing method of configuring an application is to run the application and then select various configuration screens or preferences. This is fine, until it is not.
Sometimes you cannot run the application, so can’t configure it. An example would be the Eclipse IDE. It is possible to break Eclipse by loading a misbehaving plug-in or other means. If Eclipse cannot start, one can’t remove the offending plug-in or make other required changes.
This brings up the main problem with relying on in-app configuration. Without its use, one must be skilled in the underlying configuration storage used by the app. Further, this storage may be minimally documented, complex, or in multiple places. In worse cases, this storage is non-textual. For instance, referring to Eclipse example above, I have yet to find via a web search how to easily use the OSGi Equinox run-time (that Eclipse builds upon) to remove a recently installed feature or plug-in. I’m sure it is possible, and probably minor if you know Equinox. But, how many users of Eclipse IDE have even heard of Equinox or OSGi?
- The app may be compromised or broken.
- Configuring via configuration files or other apps requires a different skill set.
- Attempts to repair via non-app UI can make things worse.
- Allow a subset of an application to be used for configuration use.
- Allow the running of the app in “safe” modes. Example, Browser without plugins.
- Create a separate configuration application.
- Allow easier means to roll back to previous configuration.
The best solution is to create a secure application that can use the target application’s configuration storage systems. If the in-app configuration support can be modularized, this is optimal.
- OSGi not usable enough?
- What is Eclipse’s Current Workspace?
- GUI piping instead of screen shots
- Home page using TiddlyWiki
- MercurialEclipse error ‘dotencode’ not supported!