Date: Wed, 14 Feb 2001 18:31:01 +0100 (CET)
This is a pre-release information note about the upcoming 2.4.6 version of
www4mail. This version is different from previous www4mail as follows:
1 New internal design aimed at more optimal use of memory and
easy extensibility:
2 Support for using dnsquery or nslookup, to determine MX records
for replying mails.
3 The AUTOLOAD subroutine has been rewritten and enhanced as follows
* supports loading of subrotuines/modules from external
files. Almost all subroutines are now placed in
external files, with loading on demand
this has improved startup time and memory usage.
I do believe that this is the way to go, I have
made some tests and it seems to run faster
* Each subroutine can specify a set of tests to be carried
out before loading, if any of the tests fails, the
subroutine does not get loaded.
This is a means of improving memory usage because
the subroutine is not loaded or parsed, if a pre
test failed. Should we have a code for ignore ?
* Each subroutine can define two sets of plugins (routines
or functions):
pre-plugins: Run before calling the subroutine
given the exact input to be passed to the
subroutine. Outputs from plugins are ignored.
the pre-plugins can modify or change the input
parameters to the subroutine
post plugins: Run after the subroutine is called.
input to plugins is the output from the
main subroutine. Outputs from the post plugins are
ignored..
For plugins should www4mail parse outputs?
* Ability to request a pre-loading of some critical
subroutines.
4 New internal design:
Internally www4mail is to be redesigned around the
following hypothetical stages:
init - Handles initialisations
mail - Handles reading and processing of request from
users
user_auth - User identification and access control
command - Handling/parsing and processing of mail for
commands
url_auth - Checks the requested URL from blacklist
browser - Fetchs the requested page or document
file_auth - Content control
filter - Handle the changing of the file content,
i.e, html and co..
reply - Handles the reply to the user, mail splitting
and posting.
The above stages are hypothetical, they serve as refrence
points for attaching plugins (both pre and post).
5 The main filter tool will be re-written as a generic parsing
engine:
HTML Tags may declare subroutine handlers.
Having a generic parser allows us to parse other file
formats other than HTML in future?
6 The following hash tables are avaibale for the purpose of
extensibility of the Autoloader:
module, protocol, tag, command
Each hash has entries with the following basic format
key : Name of subroutine, protocol, tag or command
|
- file : Location of external file
|
- pos : Position in file
|
- static : Flag to indicate a load once module
|
- handler : optional field naming another
| subroutine as the handler.
| (has a higher priority to file field)
|
- helper : Flag to indicate a helper or a plugin
|
- alias : Flag to indicate that the only valid
| field is the handler field.
|
- @pre : Array list of pre plugins
|
- @post: Array list of post plugins
|
- @test: Array list of test.
As an example, if we have an entry such as
$protocol->{https}->{handler} = '/usr/bin/curl -cmd_args'
This would indicate that curl should be used as the tool
for handling https requests.
Your comments are quite important and welcomed!