Model suggestions

This page is for discussions of important new ideas. Smaller suggestions/changes belong on the Hard Code page.

Idea	Notes	+	-
Restrict message filters	Message filters could be required either to pass messages through or acknowledge them	Makes acknowledgement more reliable	Limits options
Create a block of RDF for each module, put in the <'f2f:annotation'> chunk	Step toward presenting it all as RDF	Facilitate processing by semantic web tools.	Verbosity. Maybe just leave all the semantic web stuff for later.
Input/output validation for multi-iteration transforms	Currently, only the 1st input to these services is validated. A more complex model could specify a schema for each iteration	Would help debugging	Is it really needed?
Make own module visible to callouts?	Currently, only public services can be accessed with f2f:core. This could be expanded to include all those offered by this module.	Flexibility of coding	Security? Maybe better left until we really needed it?
Message timeout module	Communications should timeout after a certain while. This is probably best controlled from soft code, but the hardcode has to make the timeout data available somehow (e.g. move from RAM to an XML file).	More flexible/portable than hard code	Neat hard code sounds simpler