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!