cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: XSP and Cocoon2 Generators
Date Tue, 04 Apr 2000 16:12:17 GMT
Stefano Mazzocchi wrote:
> 
> Giacomo Pati wrote:
> >
> > Ricardo Rocha wrote:
> > >
> > >   http://www.casewaresa.com/~ricardo/dynamic-generators.html
> > >
> > > Briefly stated:
> > >
> > > A _dynamic generator_ can be loosely defined as an extension to
> > > "ComposerGenerator" that is dynamically created, compiled and
> > > instantiated at request time, based on the contents of a source
> > > XML document.
> > >
> > > Generators are loaded and instantiated by _generator loaders_. Class
> > > "GeneratorLoader" is an extension to "ComposerGenerator" that loads
> > > other generators in order to delegate actual XML data generation.
> > > Note that a generator loader may load any class implementing "Generator",
> > > not only dynamic generators.
> > >
> > > "DynamicGeneratorLoader" extends "GeneratorLoader" to specialize in
> > > building and instantiating dynamic generators in a language-independent
> > > fashion.
> > >
> > > XSPGeneratorLoader is a concrete implementation of "DynamicGeneratorLoader"
> > > that supports the XSP language.
> > >
> > > For code generation, XSP should use IBM's Bean Scripting Framework (BSF).
> >
> > I still have problems with the concept of the hole process. As I
> > remember a request is processed as follows:
> >
> > request -> generator -+--------------+-> serializer -> response
> >                       !-<- filter -<-!
> >
> > So, there is always ONE generator and ONE serializer. There are 0-N
> > filters. If I look with one eye at the "pyramid model of web contracts"
> > and with the other on the pipeline above, I would say that XSP has to be
> > implemented as (a) filter(s), not as a generator.
> 
> Why? (not questioning, just curious... it's great to have different
> visions)

I was fixated at the Cocoon 1 mechanics!! (clean-page.xml):-! (see reply
to Ricardos answer)

> 
> > In the Cocoon 1
> > samples directory there is the clean-page.xml samples which I found make
> > the correct process clear IMHO.
> >
> > request -> XSLT -> XSP -> HTML -> response
> >
> > This because if I am a german shop, I will have my XML-writers use
> > german tags, transform them to XSP taglibs and then go thru the hole XSP
> > machinery.
> 
> Makes perfect sense.
> 
> > There has also been discussions about putting the XSP engine into a
> > sub-pipeline.
> 
> This is how it was resolved, AFAIK.
> 
> > request -> loader-generator -+--------------+-> serializer -> response
> >             /            \   !-<- filter -<-!
> >            /              \
> >           /                \
> >   generator -> xml2xsp_filter -> xsp_compiler        <== sub-pipeline
> >
> > But I've didin't checked what is the reason for sub-pipelines. I don't
> > think it is for structuring the pipeline (I don't believe we will have a
> > dozens of filters in a pipeline). And if it is for caching (a
> > sub-pipeline ca be cached as a hole) I beleieve we can come around with
> > other approches.
> >
> > If we can tell the cocoon system which resource (i.e. file) a part
> > (generator/filter/serializer) of a pipeline uses, we can cache every
> > intermediate result of the pipeline and restart the pipelining at the
> > first step where a resource has changed.
> 
> Yes, but maybe _very_ expensive in terms of memory usage. The use of the
> double pipeline is to store _only_ the result of each pipeline and
> forget about the rest (of course, stylesheets are different and _will_
> be cached).

There is always a balance between used resources and achieved
performance. You do database denormalization because of performance as
well but it costs you disk space and managment efforts. And a cache
system as I've mentioned below will end up serving static pages most of
the time.

> 
> > If a part is dynamic (i.e.
> > SQLFilter) we cannot specify a resource or have to specify a resource
> > which changes very often (i.e. TIME) and the system has to restart the
> > pipeline at least at this part using the intermediate result that was
> > produced prior to this part.
> 
> Normally the most frequently changeable point is the generator. So, you
> waste a lot of resources by saving the intermediate points.

I can't verify that so you might have probably right ?-)

> 
> > But we can also specify a file resource to
> > the SQLFilter part in the pipeline and touch that file in a nightly
> > batch to make new results available to the requestors.
> >
> > request(URI=X) --> generator ---+--------------+--> serializer -->
> > response
> >                 !             ! !-<- filter -<-!               !
> >                 V             V    V                           V
> > CHACHE for X:   i1            i2   i3-iN                       i(N+1)
> >
> > I have great respect of the design Ricardo has made and if I've missed
> > some discussion about that theme please update me.
> 
> Hmmm, I'm not exactly sure if I see your point... you say that you don't
> think the use of sub-pipelines is necessary, is that right?
> 
> Well, while I agree with you that general sub-pipelining is probably a
> bad thing (smells of FS too much), this is a not a subpipeline but a
> special generator that reuses the cocoon engine to work.

[What's FS]

> 
> But my best argument to compile an XSP page into a generator instead of
> a filter is runtime performance: a generator spits events directly,
> while a filter interprets events generated by something else.
> 
> Well, to be quite honest, the XSP Engine is both a filter and a
> generator: it's a filter when compiles the XSP page, it's a generator
> after the page is compiled.
> 
> Since this is the only component that has such different behavior, I
> thought about using sub-pipelines as a way to go around the problem...
> but I'm wide open to other solutions, as long as we don't loose run-time
> performance.
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------

-- 
PWR Organisation & Entwicklung            Tel:   +41 (0)1 856 2202
Giacomo Pati                              Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message