- From: Onime Clement <onime@ictp.trieste.it>
- Date: Wed, 14 Feb 2001 18:31:01 +0100 (CET)
- To: www4mail-comments@w3.org
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 Suppport 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. Okay, Thats all for now! Your comments are quite important and welcomed! Clement Onime
Received on Wednesday, 14 February 2001 12:24:56 UTC