Tod Harter wrote:
I think AxKit does not need anything very specific from the Apache-API and the things I know AxKit needsOn 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.
are that low-level that mp2 aka mp1.99 would be unusable. Please note I'm not talking about addon-modules
from CPAN.
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.here I agree. AxKit's configuration possibility are not coverable easily using plain-perl at least the reset directives are
very hard to implement although not really impossible:
see http://perl.apache.org/docs/2.0/api/Apache/Directive.html
But when we start now maybe we could get things into mp2 which would make it more easily.
e.g. a $r->directive which returns $node would be one step further.
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.Send it to me. I'll take a look. I know at least that Kip also worked on AxKit as an Input/Output-Filter.
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.).
Although I think if I've been in your situation I would have done the same I think it's really sad that people
started to work on their own solutions because AxKit is bound to mp1 and I expect there are more guys like you
who are now developing their own solution.
Still maybe this way is the right way. If we can not come up with a solution which has nearly the same capabilities than Axkit1 we
should maybe start with something not as powerful and add all AxKit-capabilities when time goes by?
For me personally I reached the point in my company where I really have to look for solutions which can be used
with mp2 because in the near future all our production systems are going to work with apache2.
Please note that I don't want to blame anybody that AxKit is not working on apache 2 because I could have worked on it
myself and if I would I think my knowledge of perl and xs is good enough to get things working.
Tom
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
