cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Variations on a theme by Cocoon
Date Tue, 15 Feb 2000 06:54:36 GMT
On Tue, 15 Feb 2000, 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.

That's the heart of programming, yes. Produce output in response to input.
:)

> 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.

I don't know that I agree with this or understand 100%. First you say the
difference between the two is in their implementation; the former relies
on resources other than compiled code, the latter relies strictly on
compiled code. Then you say the difference is in their interfaces; the
former requires a parameter, the latter does not. I guess you're saying
that the latter's compiled code is created specific to a set of
parameters. I don't know if that's more optimal from a performance point
of view, but I don't see a paradigm shift; some producer still has to
create or route requests to the compiled code, which in turn creates XML
data, and thus accepts parameters. Isn't this just a shift of focus?

> 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...

More powerful how? Instead of sheparding a request through a series of
pipelines, we determine the steps a request will go through ahead of time
and pass the request off to an automatically generated object which
duplicates the effects of the request going through a series of pipelines.
This should be a win if the number of possible path permutations isn't
incredibly high. Unfortunately, that would seem to be the case for
interesting sites. Also, doesn't this presume that a request's path
through the pipeline can be predicted based solely on the the information
known at the time the request is received?

> 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.

You truly are mad, aren't you? :) You want a framework which, instead of
producing output in response to input, produces code which produces output
without requiring input, and will reuse that code in response to more
identical input. Fun idea, but shouldn't this pattern really be happening
higher up, at the JVM level? Why do you think it's enough of a performance
and functionality boost to be worth the effort in implementation and
debugging to do it in a general fashion throughout cocoon?

I contend that in cases where input varies significantly and the
computation is not very expensive, that the extra cost in code generation
and compilation is not going to be worth it. Perhaps I misunderstand
something essential, though. At what level do you not produce
output-generating code in response to input and instead just produce
output?

> 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.

Absolutely. You should really get a job as a computer systems philosopher.
:)

- donald


Mime
View raw message