<snip/> You have just provided a great example of something really close to what I was trying to express a while back when I proposed Prolog as a mechanism for "proving" URLs based on some rules, premises, and an inference engine. I don't think that it's exactly the same, but it's *very* similar.
The one thing that I see in common over the last bit of the discussion on flow and resources is the goal of moving away from the "monolithic and explicit" model to a "granular and implicit" model where some kind of inference engine handles putting everything together. I think that this makes sense for complicated resource generation, but that it might get in the way of simple resource generation. This leads to the question of whether a "one size fits all" approach to resource and flow management is appropriate? In other words are the goals of Cocoon (whatever those are!) better served by picking one approach to management or by providing a number of alternate approaches? One the one hand you have flexibility; on the other you have the potential for confusion. A similar question can be asked about web applications. For example in WebObjects a web application is basically a normal event-driven application and the environment deals with translating HTTP requests into programmatic events. I don't know if XSP or JSP have an explicit model of a web application but I don't remember seeing one. A web application could also be seen as a state machine or (and I have to admit that this is pretty cool) an application running with continuations. Is it right/appropriate/wise for Cocoon to declare "A web application must be modelled as X"? This far all Cocoon has declared (I think) is that: - Avalon is the framework - resource generation must be modelled as a pipeline - valid components are generators, transformers, serializers - components are connected by SAX events I am a little leery of enforcing a particular model of a web application, but that's just me. Thanks, Berin, for a fun and useful RT. Jason Foster --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
