cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: ldap processor again
Date Tue, 15 Feb 2000 23:42:52 GMT
donald wrote:

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

Yes, more or less.

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

No, you didn't get it.

I'm not talking about compiling a complete pipeline into a single
producer that goes directly to the output... this might be possible but
like you note, it's probably a waste of programming resource at this

I'm talking about integrating XSPProcessor ideas into the cocoon engine
so that XSP are not a special case but the very center of the thing.

> You truly are mad, aren't you? :) 

Of course.. didn't you notice yet? ;)

"only the ones that are crazy enough to think they can change the world,
they really do" :)

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

No way, that's total bullshit.

> Fun idea, but shouldn't this pattern really be happening
> higher up, at the JVM level? 

Of course.

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

No way, I'm talking about making the engine aware of page compilation
instead of creating a single producer that takes care of this, like it
is today.

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

At the XSP level and I never meant that generated producers didn't need
user input... the dummyproducer example was just an example... I meant
to say that a full-logic contained producer does not need to ge
recompiled on fly because it's not linked by any other source.

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


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