			     Stem Development TODO List

Last edited 4/12/01

This is only the tip of the real todo list. These are projects in the
immediate queue or soon after. This list is updated regularly to keep it
accurate.

Stem::Event

	add event tracing with Debug.

	lookup objects that get an event in the registry. mark that as
	the current Cell/object. use this for default from address.

Stem::Msg, Stem::Route

	enable tracing of delivered messages

	basic source routing needs design work. new client hubs will
	flood upstream who they are. master servers can respond
	downstream which will create a fully aware tree networks.

	add support for a forward. it takes a message, clones it and
	changes the to address.

	do we need an origin address? how does it differ from 'from'?
	what about tracking the path a message took?

	define the semantics of reply, from and origin address parts


Stem::Portal

	convert to use Class clone/piped support

	make other form of ssh support work.

Stem::Log

	get StemLog autoconfiguration tested

	add log file management and options:

		rotation, compression, transfer to other dirs/boxes

	all log files are suffixed with a timestamp

	timestamp is set with a template (strftime like but numbers only).

	add timer based filters. single shot cron entries to toggle
	state are fine. but how do you set the state at startup? if it
	is between start and end times, the filter should be
	enabled. this needs design work.

	define and add more actions

		email
		msg

run_stem

	write up run_stem man page in pod

	write tech notes for run_stem

Stem::SockMsg

	convert to use Class clone/piped support

Stem::Proc

	much more testing

	test pseudo tty

	convert to use Class clone/piped support

Stem::Class

	Class fields need to have supported types like boolean, message,
	etc. This needs design work and then not too much coding.


	add support for common methods to handle cloning and pipe
	creation. then if you need them, you can just do a use base
	'Stem::Class'.

	the 'clone_data' and 'pipe_data' attributes will be used for
	that.

	if 'cloned' or 'piped' attribute is set then parse_args will
	initialize them for use by the methods.


Stem::File

	design parent cell and how it spawns targeted file cells.

	code file stem based transfer stuff.

	code external ssh transfers

	later code ftp transfers based on Stem::Expect

	add file compare options - size, timestamp, MD5

	add single directory support.
	filename filters

	add tree support

	add support for ftp and scp

	add throttle support? don't want to slurp entire large file in
	and clog the system. throttle with reply messages and/or timing

Stem::State

	design basic state machine

		current state token

		input value -- message, callbacks, direct method

		regex matches

		output value -- message, write method/callback?

		new state token

	state object does not do i/o. it is driven from the outside with
	a single input argument. state failures can be ok (an optional
	flag) and just cause more data to be read and resubmitted to the
	stae machine. so if expect is not timed out it waits for more
	data. a timeout is used as input to the engine for where to
	go. maybe that is a special state input that uses a method
	instead of a string:

		$output = $state->next( $new_text ) ; # normal call
		# returns undef on failure to match.

		$output = $state->next( $new_text, 1 ) ; #  call

Stem::Expect

	use proc or socket and use async IO

	hook in Stem::State

	expect handles timeouts from async IO. then it drives the state
	machine with a timeout method. regular input is sent to the
	state machine as data. 

	if no input matches but not timed out yet, we wait for more
	input or the timeout.

	do we need code callbacks? i think the higher level object
	(protocol::ftp?) would want callbacks itself in some cases. 

Testing

	need unit tests and incremental tests during development.

	need tests for higher level cells.

	need load testing of various subsystems.

	need cross platform testing.

	in the intermediate term (6 months to a year) i envision a set
	of test boxes, consisting of a variety of brands of hardware and
	OSs. we can use low priced stuff and whatever we scrounge
	up. Stem would be configured to run over all the boxes (we make
	it easy to add/delete hardware) and continuously test load, long
	term stability, interoperability, regressions, etc. there will
	be a single person/group responsible for this test envionment.

Documentation

	full pods for all modules

	accurate docs for all class fields. this can be autogenerated
	from the $field_info lists. we could parse only that code out
	easily and eval the string. the either edit the internal pod or
	some other text file. it would generate a nicely formatted
	description of all the class fields.

security

	support stunnel which should be easier.

Tracing

	mark by name which message is currently being delivered

	use the hub/cell/target in the 'to' address.

	any newly dispatched messages get a from/origin of that to

	just copy the to?

	fix registry lookup by object to get cell/name and target

	save current event cell name and target

	create trace file to be written by events and message delivery
	(or dispatch?)
