This is one of TimLegant's pages, not mine, so ignore it unless he resurfaces. I am adding my thoughts to TmdaOneDotTwoTodoList instead. -- JasonMastaler (2006-09-16 06:55:56)
Overview
This page is an overview of (and sometimes a rationale for) the internal design of TMDA moving forward from TMDA v1.0. The primary point of these choices is to enable the TmdaOneDotTwo features. We want to reorganize the internals of TMDA so that third-party utilities can more easily use core TMDA facilities. We want to eliminate redundant code by combining multiple code fragments performing similar tasks into single, more general interfaces.
Discussion related to any topic here should take place on the tmda-workers list. Expect this page to be reorganized and updated based on discussions that take place there.
1. General
These are areas that will affect more than one part of the design. They are grouped here for background and as pre-suppositions for some of the following ideas.
Easier ISP / virtual user / mailhub configuration Not a whole lot of specifics here, yet. Database configuration for individual users should be possible. There should be no assumption that a user has a home directory; particularly, any pathname that uses a tilde to represent a home directory must be overridable. At a conceptual level, the tilde provides a shortcut meaning "the location where user-specific data is stored." This kind of shortcut must be available for virtual users and database-based configurations, not just disk-based, system-user configurations.
Separate loading of global and local settings Global settings (/etc/tmdarc) will be loaded when Defaults.py is imported. Local settings (~/.tmda/config, database?) will be loaded when Defaults.load_user_config() is called. This allows programs to configure their initialization behavior based on settings in /etc/tmdarc. As an hypothetical example, if VIRTUAL_USERS (doesn't yet exist) is set to True in /etc/tmdarc, a program like tmda-filter can adjust where it searches for an individual user's config (database or disk). Currently, tmda-filter can set $HOME to a path other than the default so that '~' refers to the new path. This only works for qmail and is a rather ugly hack. Other opportunities to take advantage of this may present themselves. This also implies that certain variables MUST be set in /etc/tmdarc. Which variables these are will depend on the particular configuration (if a database is being used, the database connection information would obviously have to occur before trying to read the user's config from that database). If a feature requires a variable to be set in /etc/tmdarc, it should be documented as such. In the rare case that a particular user needs to override a global setting, an environment variable can be used, as in "make -E".