cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flowmaps revisited
Date Sun, 14 Oct 2001 08:23:10 GMT


Jason Foster a écrit :
> 
> This is fun! :)
> 
> > Meanwhile, and just to add some FFT, I think that some previous study on
> > finite state machines might help the discussion. I found really
> > valuable, while oriented specifically to concurrency issue, the
> > Magee&Kramer book (Concurrency. state models & Java programs) which uses
> > heavily the FSP (Finite State Process) formalism together with the LTS
> > (Labeled Transition System) modeling.
> 
> I was poking around Slashdot and noticed a thread on Lisp, which in turn
> mentioned Haskell.  While I've never used either language extensively, it
> looks to me like a functional approach to expressing a web page or
> application may have merit.
> 
> Based on my very limited knowledge, instead of defining all states and
> transitions explicitly, you specify individual dependencies and let an
> inference engine take care of things.
> 
> This sounds neat as it allows SOC within the webapp definition.  Two groups
> can work on different aspects of the webapp independently, and then the
> system can integrate them once a single dependency is defined.  Of course
> you could probably do this in a state machine as well...
> 
> The more I think about it, the more I think that there are two distinct
> aspects to Cocoon.  The first is the underlying plumbing (Generators,
> Transformers, Serializers), based exclusively on the decision to use a
> cached SAX stream.  The second part is the mechanism that links the plumbing
> together (Sitemap, Flowmap).
> 
> I'm about ready to propose that Cocoon should *not* impose any particular
> way of connecting things, in the same way that we don't impose any
> particular way of generating SAX events.  It would be really cool to allow
> people to use State Machines, Inference Engines, JavaScript, Python, the
> Sitemap, or any other thing they can dream up to connect the basic
> components.  Sort of like "Avalon for XML"?

Agree with that : with the recent discussions on the tree-traversal
implementation of the sitemap, there comes a need to cleanly separate
the current implementation of the sitemap from the Cocoon class itself.
For now, they're a little bit intermixed and Sitemap isn't handled like
other components in cocoon.xconf. Once they're separated, the door will
be opened to alternative implementations, the first one being the
interpreted sitemap.

> But that's another story ;) (1)

Or maybe not ?
 
> Jason Foster
> 
> (1) I always liked Hammy Hamster, for all you Canadians out there ;)
> 
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message