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
|