cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Foster <jafos...@uwaterloo.ca>
Subject Re: [RT] (long) Rethinking Finite State Machine Approach to Flow Management
Date Fri, 30 Nov 2001 18:38:17 GMT
<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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message