On Monday, March 24, 2003, at 09:39 PM, J�rg Walter wrote: <snip>
Phew. Heavy stuff. I am happy someone tried that. Yet give us some time to
digest that, try it out and everything. These changes are so deep, maybe they
should be scheduled for AxKit 2.0, then possibly without backcompat-hacks...
Anyhow. I'm eager to try it, maybe it will solve some of my problems I wanted
to tackle for so long.
The changes are reasonably deep - but it's mostly contained within the AxKit.pm module and everything else is pretty backwards compatible (with the exception of the Cache API - of which I can't find any derived classes anyway).
Did you profile several scenarios? How is performance with this system? Doesn't it add too much overhead?
I haven't really profiled anything - I just tested with various pipelines. However I can speculate. There will be more checking of cache files (once per style rather than just once), and a little more in the construction of provider classes. But I think there will be some gains made by not trying to do everything via pnotes, and of course there will be significant gains due to increased cache effectiveness. For example if there is an XSLT transformation followed by XSP, the XSLT can now be cached even though the XSP result is uncacheable.
Does "return 404;" from XSP still work? (which should go on processing, but
send the final result with $r->status(404))
I haven't really checked that - but I see no reason why it wouldn't. The status method wasn't proxied by AxKit::Apache, so it should work as normal. It seems kind of ugly doing that though, since you can't be sure what else is down the pipeline.
What about "throw Apache::AxKit::Exception::Retval(return_code => 403)"?
(should abort immediately and just send the given error code).
Again - I can't see any reason why that wouldn't work as normal. The exception handling is unmodified (except for the removal of the unused OK exception).
Please, have a play with it and see if you can find any problems.
Regards, Chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
