Life used to be so simple / unconfigurable

I had a spare hour this afternoon, so I thought I’d take a quick look at how dspace.cfg has changed over time. Anyone who has had the pleasure of looking after a DSpace server will know about dspace.cfg. It is the main configuration file for DSpace where many of the configurable options reside. These vary from core settings such as the name of your database server or mail server, to minor tweaks that make differences to your repository that nobody would ever notice!

DSpace 1.7 has just been released, and as it stands, dspace.cfg is a whopping 2268 lines long, containing over 200 required or preset configuration options, and a further 250+ optional parameters.  That’s quite a configuration file!

(It’s not so bad though – to get a new system up and running requires less than 5 settings to be edited to match your local environment.  The rest are there for a rainy day.)

But… how has it grown over time?

  • Version 1.0: 31 required / preset, 2 optional
  • Version 1.1: 30 required / preset, 5 optional (-1, +3)
  • Version 1.2: 34 required / preset, 9 optional (+4, +4)
  • Version 1.3: 55 required / preset, 32 optional (+21, +23)
  • Version 1.4: 101 required / preset, 58 optional (+46, +26)
  • Version 1.5 : 157 required / preset, 104 optional (+56, +46)
  • Version 1.6: 195 required / preset, 227 optional (+38, +123)
  • Version 1.7: 215 required / preset, 257 optional (+20, +30)

Or if you want to see it as a chart:

(N.B.: The gaps in between each release do not always reflect the amount of time or code changes in that version, but as a subversion repository as a whole.  The darker area are the number of required / preset configuration options, and the lighter shaded area the optional settings.  The number of optional settings is a rough calculation, looking in the configuration file for any line that starts with a ‘#’ (a comment) and contains and equals sign.)

That’s obviously quite a change – from humble beginnings.  I think everyone agrees that something needs to be done to help the system administrator / repository manager navigate and understand the plethora of configuration options.  However there are many different options / preferences / views about how this is best tackled: multiple configuration files, configuration stored in the database, configuration managed via spring services, DSpace installers, etc. One will have to win…сайт

4 thoughts on “Life used to be so simple / unconfigurable

  1. Mark Wood

    Actually we may need more than one winner. If the configuration is stored in the database, DSpace will need to identify the database and provide credentials, which must be provided by other means.

    Also, if the configuration is stored in the database, we’ll want a tool for manipulating it. The tool will be general but the specific configuration data will evolve, so now the *tool* will need to be configurable. Eventually it will even be localizable.

    Likewise, an installer’s interaction with the user will most likely be driven by something like a script. That is to say: configurable.

    There are at least two separate issues here: how we store configuration data, and how we expose them for inspection and modification. Currently the storage mechanism *is* the presentation mechanism, and as the number of configurables grows this identity has become part of the problem.

  2. Amanda

    My institution is about to let loose 1.7 on our unsuspecting public. (that’s what happens when it takes several months to get an upgrade, another version pops out.) If you’ve got a spare hour I’m sure i could drum up some folks interested in listening and asking questions about this ‘candy code’ you mention. I could organize a recorded audio conference…. interested?

  3. Amanda

    thanks for the link, Stuart. I have just watched it and it was helpful. (not sure how i missed it back in feb).

Leave a Reply

Your email address will not be published. Required fields are marked *