xml-axkit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schindl <tomAtLi...@gmx.at>
Subject Re: Changing the Pipeline Model
Date Tue, 20 Apr 2004 07:29:05 GMT
Matt Sergeant wrote:
>> (A push pipeline, each stage is run independantly, the output pushed
>> to the next handler).
>>
>> A pull pipeline looks just like a function call stack, starting at the
>> outside... which means each stage ask the stage before it for the
>> representation it wants before getting it, which allows for lots of
>> self optimisation.
>>
>> send( get_binary ( get_text ( get_dom( get_dom( get_dom( ) ) ) ) ) )
>>
>> (in the code this is the $self->upstream()->get_dom() stuff).
>>
>> The (dis)advantage is that the pipeline gets created first, before things
>> like the cache get created, which allow for the cache to interact with 
>> the
>> pipline (and thus XSP). The disdvantage is is that it's a little 
>> slower than
>> the current axkit due to this overhead.
>>
>> It however also means that we can make the cache just another pipeline 
>> module.
>> So incremental caching is available if you want it out of the box.
>>
>> AxKit.pm is a lot smaller.
>>
>> Chained XSP works.
>>
>> Chained sax handlers work the way you would expect them to, they're 
>> just a style
>> using the Apache::AxKit::Pipeline::SAX processor
>>
>> Error stylesheets have been fixed, there is an Error Provider now 
>> which you need
>> to set up as you server 500 handler.
> 
> 
> Before I chime in on Kip's "Wake-Up" thread, which I will try and do 
> tomorrow, I want to address this issue, and start off a new thread on 
> it, so the WakeUp call doesn't get bogged down in discussing this side 
> issue.
> 
> We need to come to a decision on this - whether to fundamentally change 
> our pipeline model in AxKit-2.0.
> 
> As I see it the arguments for/against are something like this:
> 
> For:
>  - The pull model cleans up some code
>  - The pull model already supports some things we've wanted for a while: 
> e.g. Chained XSP and more flexible cache

I'm working on chained XSP by using my new XML::LibXSLT::Enhanced(a new 
module of mine) which allows you to add perl functions inside your XSL. 
As a proof of concept I reimplemented your ESQL-Taglib. With this 
approach you can easily chain XSP because it's nothing more than an 
XSL(T)-Pipeline.

At the moment the following things are supported:
* defining your own variables (to overcome: you only set a variable once
   in xsl)
* logging via log4perl (that's really fantastic to debug XSLs)
* esql (not competely ready yet)

It also comes with a commandline interface named xslt-proc-enhanced 
which allows you to register TagLib's out side of the AxKit-Context and 
test your xsls like one is used to with xslt-proc.

The module is not ready for release on CPAN still if somebody is 
interessted in it I can publish the code. At the moment one can also use 
http://search.cpan.org/~tomson/Apache-AxKit-Language-LibXSLTEnhanced-0.02/ 
  this was my first try on adding something like TagLib's to XML::LibXSLT.

Please note when writing TagLib's using this module they will not be 
compatible with XML::LibXSLT::Enhanced-TagLibs.


>  - The pull model means some cleaner code
> 
> Against:
>  - It's a big change. This means a change for developers and users alike 
> to get used to.
>    - (Meta For argument) - 2.0 is as good a time as any for big changes
>  - Some of the things the pull model does should be possible with a bit 
> more work using the push model, without breaking anything else.
>  - There's no easy way to change the pipeline mid-stream with a pull model
> 
> I don't exactly know the right answer to this, so if you have input into 
> this send it now. I think what really has to happen is we have to 
> download this new code and play with it, and see what we think of it 
> from an individual point of view, and then come back here (and not IRC) 
> and discuss it openly.
> 
> Matt.
> 
> 


Mime
View raw message