On Sunday 14 November 2004 12:27 pm, Tom Schindl wrote:
Tom, I've been doing some pretty heavy mod_perl work on Apache2...
1) The API, while useable is still pretty buggery. The main problem is that
unless you have a certain exact mod_perl version, things tend to blow up,
which makes it a real PITA to code for, IE 1.99_17 has certain bugs, 1.99_15
has different bugs/deficiencies, not unusual but its especially pronounced in
mod_perl 1.99xx. To get my stuff working I've found over 50% of the code is
version/regression hacks and certain parts of the system are still REALLY
rough.
2) The most rough part is config, which is one thing AxKit always did really
nicely, so it looks like to build in configuration capabilities equivalent to
AxKit 1.6 has on 2.x Apache is still not possible as of 1.99_17, at least not
in perl.
As for your other observations, I agree basically, but I'm not the most
qualified person to comment since I didn't delve a great deal into AxKit
internals.
What I was able to do:
Created a module 'XSLTOutputFilter' which applies an arbitrary XSLT
stylesheet, ALA AxKit's XSLT language module, including ability to have perl
callbacks etc. Configuration is ugly due to the deficiencies I outlined
above, but the code works good, it caches stylesheets parsed in memory and it
reloads them if they change, so I believe its roughly the same functionality
you have now in AxKit's version. Given that you have perl callbacks I didn't
bother to implement any way to get input params into your stylesheets, but
that would naturally be handy when you're working with existing XSLT!
Currently It uses the streaming filter interface, but I THINK if I understand
bucket brigades correctly you SHOULD be able to chain several of these
together and brigade the DOM from one to the next without serializing. Or if
that isn't possible then I guess there's always 'pnotes' :). That would
increase efficiency greatly in real-world scenarios.
In terms of providers, you're entirely correct. Given that all modules can
filter each other 'Providers' move out of the realm of AxKit itself, though
it would be nice to create a 'smart content provider' module which would know
how to cache generated content. Not much different from the existing provider
modules but they wouldn't be tied to AxKit anymore.
Anyway I'd be happy to have other people hack on my stuff if they want. Its
not really CPAN-ready at this point (no tests, no installer, etc.).
As an example of my non-to-polished code's configuration:
PerlLoadModule Apache2::XSLT::OutputFilter
# declare an XSLTOutputFilter
XSLTOutputFilter
activeorders /var/www/web.thebeast.local/stylesheets/activeordershtml.xsl
# a location that uses it
<Location /activeorders>
# don't need this except when using a PerlResponseHandler
SetHandler modperl
# this just outputs some data, it could come from a static file
PerlResponseHandler $OpenTrade::marketview->handler
# This is SUPPOSED to add my XSLTOutputFilter to the chain, but as of now
mod_perl is too broken to support this...
SetXSLTOutputFilter activeorders
# So this ugly hack does it!
PerlOutputFilterHandler
$Apache2::XSLT::OutputFilter::__activeorders->handler
</Location>
The idea here is you can DECLARE XSLTOutputFIlters at the top level, each
bound to a stylesheet it processes, and then in any container (or FILES
directive etc) do a SetXSLTOutputFIlter <name> and that filter will be
applied. Multiple ones stack up, so you can get some of the features that
AxKit provides. One area missing is all the functionality currently in
StyleChoosers (ie select based on media type or root tag or extension or
request attributes). Those can be easily built and since you can now directly
manipulate the output filter chain they should be very easy to write.
So basically what I need is:
Caching of dynamic content
Advanced Style Choosing
Other types of filters besides XSLT
thats about it!
> Hi,
>
> because of always reoccuring thread about AxKit on Apache2 I thought
> that I'll give it a try and summe up my ideas about the whole thing,
> some already discussed sometime a go:
>
> 1. AxKit on Apache2 is in my opion nothing more than an Output-Filter
> 2. AxKit::Provider::* is not needed any more because if AxKit is an
> output filter any arbitary Apache-Module can provide its input to
> AxKit.
>
> I think it should not be too hard to get the AxKit-functionality into an
> Pure-Perl-Implementation for Apache2. If we would give it a start now
> which we ***really*** have to because we are already very late to get
> things working for Apache2, most other frameworks are already compatible
> to Apache2 :-(
>
> Tom
>
>
> Reclaim Your Inbox!
> http://www.mozilla.org/products/thunderbird
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
