Architecture

Anzu is designed with the intent that customizing mailing list behavior should be customizable without code changes. Several mechanisms are available, accessible at different points: overriding an individual option for a list, choosing a list type for a list, changing the set of list types, changing the set of option types, and mlm specific conf files.

The way that options and list types interact is defined extensively in the design doc, but some examples may illustrate this. An option is a individually configurable setting, such as whether or not messages are moderated, or what string should be placed in the subject header (if any) to identify messages to this list. A list type is a collection of options which together describe how a mailing list should work -- for example, a type called 'announce' might be defined, which would be the set of options appropriate for lists used as low-traffic, moderated mailing lists.

Changes available

Overriding an individual option for a list

The simplest approach to changing how a mailing list behaves is modifying an individual option. This will leave all other options as they are; used incorrectly, this can result in unexpected behavior due to the often complex interactions amoung the options, which often involves MLM specific information. Generally a limited set of individual options should be exposed.

Options can be either boolean values or strings (which are different types of options).

Execution: Use the admin UI or the command line tool harness to set the option. A limited set of options are available through the admin UI; the harness tool allows you to set any arbitrary option.

Choosing a list type for a list

Choosing a list type for a new list specifies the initial values for all the options which the list type defines. Choosing a list type for an existing list applies the current definition of the list type to the list, overriding whatever options are currently in place. Used incorrectly, this can override modifications to individual options -- some of the APIs allow applying a list type while making exceptions for a specific list of options, but these generally require the list of exceptions to be specified.

Execution: Use the admin UI or the command line tool harness to choose the list type; the admin UI should generally maintain whatever options it managed explicitly. The command line tool harness will allow you to specify a list of options whose values shouldn't change -- these are specified last, on the command line.

Changing the set of list types

The set of list types can be changed by modifying an existing list type or by changing the set of list types. Neither of these operations will change existing lists -- but there are command line tools which allow easy scripting of the operation of re-applying list types to all lists. Currently, modifications to list types cannot be done through the interface, but that may change at a later date.

Changing the set of options for a given list type may cause it to behave incorrectly, if the resulting set is not appropriate for the MLM in use.

Execution: The admin UI does not currently support this. The command line tool harness allows modification of an existing list type within a specific domain (if the domain is deleted and recreated, the modifications will be lost, of course). Changing the set of list types requires editing conf/anzu/anzu.properties for the version 1.2 and later, and data/anzu/properties/anzu.properties for versions before 1.2.

Changing the set of options types

Changing the set of options types is potentially very dangerous, in that incorrect configuration can result in security exploits. This can only be done on the command line (not through the admin UI), and that will not change.

Execution: This requires editing the option_types.txt file which anzu uses. Technical knowledge of the internals of the specific MLM(s) in use is required for this.