Configuration and sessions

Ensembl has two different types of configuration: system and user.

System configuration

System settings are controlled by the administrator of Ensembl.

Apache web server configuration

The SiteDefs.pm Perl module holds the information required to build the httpd.conf file to configure Apache (i.e. port number, modules etc). Some knowledge of Perl is required to edit and maintain this file.

A SiteDefs object is instantiated by the parent Apache process, and is made available to all scripts served by a child process. The role of Apache in serving pages is discussed in Apache Loop.

Site configuration and species definitions

A series of .ini files are used to specify virtually every other configurable section of Ensembl. These are easier to configure than a perl module and are only needed by the child processes. The DEFAULTS.ini and MULTI.ini files contains a set of default settings for all species, but each species appearing in Ensembl can augment or overwrite these settings with its own .ini file. All these files are located and parsed at server startup by EnsEMBL::Web::SpeciesDefs.pm.

Configuration options specified in the .ini files include (but are in no way limited to):

• Default database connection settings
• Homology search settings
• Paths to utilities used by the site
• Parameters that control the look and feel of the site

Accessing system configurations

As the information from SiteDefs.pm is pulled into SpeciesDefs.pm, all these settings (be they server, site or species) are accessible from the global package SpeciesDefs. No instantiation should be necessary to access the settings as the SpeciesDefs object is instantiated early by EnsEMBL::Web::Page and then passed around.

User configuration

Seperate from the actual system configuration, it is often helpful to store additional configuration information on a per user basis. For example, should a user elect to hide a number of tracks, it makes for a better user experience if Ensembl remembers those changes for subsequent visits to the site. Ensembl does this based on user sessions.

Sessions

Any time a user makes a configuration change to a view in Ensembl, a new user session is started. This links a particular browser to a particular Ensembl configuration, by storing a cookie containing a unique identification number in the browser. The cookies are only created when needed, by EnsEMBL::Document::WebPage. They store an encrypted version of the session ID from the %ENV variable (instantiated by the Post Read Request handler).

When a new session is started, a new entry is made in the optional WebUser database and all configuration changes are stored against it. This ensures that configuration changes are persistant per session.

Accessing user configurations

Two modules are used to maintain state in this way: UserConfig and ScriptConfig. Both use the same WebUser database for storing and trieving information, and both check and create session identifiers if necessary.

• UserConfig is used to store information about a particular view's images. For example, which tracks are active.
• ScriptConfig stores options for a particular script or page. For example, the width of the page, which panels are visible and which are collapsed.

Instead of saving all configuration options in the databse, these configuration modules actually store the difference from the default settings. With this implementation new default options will not be overridden by older session information.

Footnotes on ensembl_accounts

• The UserConfig reads the session ID from the cookie and then looks up the session data in the ensembl web user database (ensembl_accounts). If this database goes down, session data requests back up and eventually the whole site does down.
• Data is not deleted from the ensembl_accounts database.
• The user logins system uses the same database but different tables.