Configuration

Configuration

Configuration variables are set in the following files

• global.conf --- where most of the configuration variables reside. Evaluated as perl code for each request.
• course.conf --- anything in global.conf can be overridden on a course by course basis in course.conf. Evaluated as perl code for each request.
• simple.conf --- this file has a simplified syntax and is written by Instructor/Config.pm. It is read at the same time as course.conf (not sure which is dominant of these two)
• WeBWorK/Constants.pm --- has some constants that need to be set when the child is read (and before global.conf is read). In principle this should contain settings that are rarely changed for individual sites except when debugging. In practice other settings have been added, such as those governing the choices on the CourseConfiguration page which might be better set in global.conf. Some thought and refactoring of code is in order.
• conf/templates/XXX and htdocs/css/XXX.css --- these files govern the themes for each course.

In some rare cases constants are being set in the .pm files that should be set in global.conf. They were set that way while the files were being written and since there has seldom been a reason to modify them they have not yet been moved to global.conf. In some cases they should remain where they are, too many choices in global.conf is as bad as too few.

With that in mind I suggest a project to change global.conf so that the upgrade process is simplified. Currently when upgrading I go through a line by line diff between global.conf and global.conf.dist to see what needs to be changed. This could be simplified if we had the following system

• prelocal.conf -- read before global.conf
• global.conf --
• postlocal.conf -- read after global.conf

The prelocal.conf would be required and would set variables such as where the pg directory was located, or whether the basic unix tools are in /usr/local/bin or /usr/bin.

The global.conf file would be designed so that in the vast majority of cases it could be copied from global.conf.dist without changes of any kind. (This is largely the case with database.conf already.) This will greatly facilitate most upgrades since the additional configuration data needed for new features can be safely copied into the existing global.conf file.

The postlocal.conf file will provide site wide overrides for configurations normally set in global.conf --- for example what are the permissions allowed for ta's --which is often a site or even a course preference.

Course and personal preferences

• Current session state variables
  • Display type -- jsMath, mathJax, dvipng, etc.

• • In some cases when editing the source code for the problem is preserved in the HTML code.

• Current course state variables
  • Permitted display types (jsMath etc.)
  • Course time zone
  • Course permission configuration ( a subset of all permission configurations available).
• Additional session state variables desired.
• Additional course state variables desired.
  • Language localization
  • Date/Time format localization

Database implementation of session state

A closely related project is to maintain user and course preferences during the session or across sessions and courses. This is a database project.

• Course preferences are preserved either in course.conf or in simple.conf.
• Currently state is preserved during sessions by constantly passing it as hidden variables in the HTML. This works but a database solution might be more efficient and more secure.