Request For Comments : New www4mail 2.4.6

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