cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Variations on a theme by Cocoon
Date Mon, 14 Feb 2000 23:01:53 GMT
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.

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.

Anyway, the step forward is soon taken: 

  what happens if a producer is generated from a complete Cocoon
pipeline process?

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.

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

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


Mime
View raw message