<snip type="lots of interesting ideas"/> One thing I would like to inject into the discussion is the idea of switching from a (I think I've got this right) imperative to a declarative approach to defining the FSM.
The example FSM given by Berin is described in what I would call a classical imperative approach. The whole FSM is defined in one step by enumerating the states and the transitions. The complexity of such beasts grows extremely quickly ( O(n^2) with a small constant depending on sparseness, IIRC) and they soon become a real pain for a single mind to grasp. I was looking at Prolog recently and thought that you could define something a lot like an FSM using a declarative approach. Basically instead of having to define all of the states and transitions at one time, you treat the problem at the level of individual states and their preconditions. The inference engine then decides if a particular transition is legal. Moving away from the FSM example, consider the example of generating a reply to a URI. Right now we declare the pipeline explicitly. We match on the URI and then process away. An alternative would be to consider the URI as a proposition and the "sitemap" as declaring a set of axioms. When a request comes in an inference engine determines if you can "prove" the URI using the axioms. Each axiom could add something to the output stream or to whatever it is that actions use to store their results. The the URI is "provable" then we send the reply to the client. If it isn't, then we send a 404. The reason I thought this approach might have some merit is that it may reduce the complexity of the sitemap. Instead of having to worry about all of the states and the overall flow through the system, you only worry about single states/actions and their preconditions. The inference engine takes care of actually hooking everything up. There are a number of Open Source implementations of Prolog and similar languages that we could adopt if this looks to be a good idea. I think that this approach complements, not replaces what Berin was proposing. Of course once Cocoon's "control" mechanism (Sitemap, Flowmap, etc.) is made into a component controlled by cocoon.xconf we can have all sorts of different mechanisms! It's not confusion, it's choice ;) Just a thought. Jason Foster --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
