cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zvi Avraham <>
Subject Re: Variations on a theme by Cocoon
Date Tue, 15 Feb 2000 04:27:34 GMT

Stefano Mazzocchi wrote:

> Well,
> it's been I while I reconsidered the whole thing from my whiteboard
> perspective.
> In case you don't know, I hate programming and like architecting and
> designing a lot more. My brain is mostly visual.
> Anyway, the Cocoon2 architecture was based on Cocoon1 and mostly didn't
> change from what it's already in Cocoon1 but many side things were added
> (SAX, sitemap, servlet-abstraction).
> But the architecture is still the same:
>  in -> transform -> out
> this is the very basic idea that, all removed, is the real power of
> Cocoon: everything is based on the assumption that a content-producing
> process can be divided into these three stages.
> I did many confrontations, either technical and topological about the
> above and came to the conclusion that that pattern is rock solid: no
> matter what, you can always fit your process into something like the
> above. And guess what? by doing this, you make it far more cleaner.
> The above is an extention of the good old pipe and filters design
> pattern, but includes also the notion of "adapters". In fact, the model
> can be expressed as
>  something -> adapter ===> transformer ===> adapter -> something
> where -> represents streamed transport and ===> a more ordered and
> structured transport (SAX, DOM, whatever).
> Adapters are parsers and printers. Adapters are FileProducers and FO
> renderers. Anything that connects the outside world with the inside XML
> world.
> It's amazing for me to see how many things changed over more than a
> year, but not the single idea that made all this possible.
> Today, I'm reconsidering it. Not because I think it's wrong, but because
> we need something more.
> Ok, I added a lot of space because we need a little room... wipe out
> your whiteboard and follow me...
>  what is a cocoon producer?
> It's a component that creates XML content.
>  ok, but where is the ┬░information┬░ that drives this generation?
> let's consider a few cases:
> 1) fileproducer: the "information" is stored in a file, the producer
> contains the logic to create the XML content based on these
> instructions. In short, this is a parser, but it could be viewed as an
> interpreter: it reads a stream of chars and generates structured
> content.
> 2) dummyproducer: the information is compiled in. the producer doesn't
> contain any more logic than spitting the structured content as it is
> compiled in.
> Now, are these two any different? from a behavioral point of view, it
> appears no: both producer XML output.
> But from an operational point of view, these two are _completely_
> different!!! The first is a general purpose pure-logic container. The
> second is a compiled version of the first.
> There is a _huge_ difference between the two... and this is reflected in
> operation: fileProducer needs a parameter that indicates where the file
> is, the second does not since no futher information is needed to create
> the page.

DummyProducer doesn't need parameters just because it's DUMMY :-)
Something just a bit more complex will need at least one parameter (static -
in configuration or dynamic in request).

> Of course, compilation for static files is not that useful, expecially
> for large files, but this triggers many more paradigm shifts:
>   what is the difference between stylesheets and filters?
> stylesheets need interpreters, filters generally don't. I could be
> possible, in theory, to "compile" a stylesheet in a filter, even if this
> is probably the equivalent of compiling an XML file into a producer to
> avoid parsing overhead, so not much useful.

I see XSLT Processor as filter, that takes parameter - stylesheet (+
parameters of stylesheet :)

> Anyway, the step forward is soon taken:
>   what happens if a producer is generated from a complete Cocoon
> pipeline process?

That's will be amazing! If every path in sitemap will be compiled into
Servlet (or Servlet-like class), then we will have SUPER HIGH PERFORMANCE
web publishing system.
Cool idea: is possible to compile SiteMap.xml into Servlet 2.2 API's
server.xml + WEB-INF/web.xml + Servlet class for each path in sitemap.
Further it's possible even to package the entire thing into one WAR file,
which will automatically install itself into any Servlet 2.2 container.
What do you think?

> Then what we have is a wonderful new approach to the whole thing, not
> really different, but _much_ more powerful...
> Let's wipe the whiteboard again... now consider XSP
>   content -> apply logicsheets -> compile -> execute -> apply style ->
> out
> and then consider a normal cocoon pipeline of
>   in -> transform -> out
> well, the two don't match!!! Why? in the original Cocoon pipeline there
> was no notion of "execute".. which means: use the output of the previous
> stages are the instructions for the "turing machine itself"!!!, not as
> instructions for the pipeline.
> This is a paradigm shift and this is also the reason why I don't like
> Ricardo's implementation as a processor and also the reason why XSP
> don't work as expected as far as reloading is concerned and
> performance-wise.
> Now, let us consider what XSP do: they indicate a way to include XML
> into source code. Following our design patterns, this is a serializer.
>  file -> logicsheets -> source code
> Ok, if we add a little piece, we come up with
>  file -> logicsheets -> source code -> bytecode
> all done inside a serializing component.... then, if we add the ability
> from inside the cocoon processing engine to "instance" and execute
> bytecode generated from inside the pipeline, applying normal caching and
> reloading issues, what we have is a distribution of the XSPProcessor
> functionalities inside the cocoon engine... allowing total reuse of
> existing resources and full-speed.
> In fact, while current XSPProcessor does work like a processor and so
> requires parsing to always take place, the improved "recursively
> instancing" engine allows the producer to be called directly, being it
> associated with the pipeline that generated its bytecode.
> also, like for any other data, if something changes inside the pipeline
> that generates the bytecode, the regeneration takes place, even if
> logicsheets and/or original file were changed.
> It's been a while I'm thinking over this and Pier already knows part of
> this... I didn't say anything before because the fog was not clear in my
> mind and the implementation details were too blurry...
> today they are more clear but I'm not that focused yet... anyway I'm
> confident that Cocoon2 will be based on such design, allowing all
> producers, no matter where they come from, to be treated equally.

Sounds OK to me, but I wandering if possible to "linearize" entire path of
producer -> filter -> serializer
producer -> filter1 -> filter2 -> ... -> filterN -> serializer
compile all this into one .class file (Servlet) ?

Then you even don't need Cocoon in runtime, only in design time (compile
time? :)

> Sorry for the long mail, but I think it's good food for thought.

Not so long, comparing wih Clark's mails :)

> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------


View raw message