Matt Sergeant schrieb: > On 17-Aug-06, at 3:05 PM, Steffen Schwigon wrote: > >> Matt Sergeant <[EMAIL PROTECTED]> writes: >>> I need a few +1s to put up a download for AxKit2. >>> >>> Voters are: >>> >>> kip, darobin, barries, jwalt, mach, nachbaur >> >> Just for the list lurkers, what's the relationship >> between AxKit2 and TomKit? Is there any? > > There isn't really any. >
Right. Beside the fact that I was inspired by AxKits concept of providers, processors, ... . > TomKit was born out of Tom's frustration that we had made no progress > porting AxKit to Apache2/mod_perl2. He offered it as a potential base > for us to start with. As yet TomKit has no configuration directives > (probably the hardest part of a port), and no XSP, and the API for > everything is different to AxKit1. > Right we (my company) decided at one point in time to switch all our servers to Apache2 and didn't wanted to maintain a apache1 sitting behind our apaches only for AxKit and because I'm not a C-guru at least I didn't wanted to learn the Apache-Internals to port AxKit1 straight to Apache2. Well what do you mean with configuration directives? What I'm using for now to configure Apache2::TomKit is PerlSetVar and PerlAddVar in future versions I'll also provide those things as configuration directives which shouldn't be that hard than it was in Apache1 because mod-perl provides hooks for it. At the moment many of the AxKit-Directives have no counter parts because I didn't needed them for now in my own projects but in the end all AxKit-Directives should have counter parts in Apache2::TomKit. XSP is not part of Apache2::TomKit because I was and will maybe never been a friend of it and didn't had the feeling to port it to Apache2::TomKit or in other words it's on my priority list at a very very low level. I agree that to make it easy for people to port their applications it is needed but I have to plan where my few spare minutes are going to. Why I decided to create a new API is that I wasn't happy with the one of AxKit and I doesn't liked the mixture between Object-Oriented stuff and normal perl-code if I remember correctly but I could be wrong here. Nevertheless it's heavily inspired by it and porting modules for example processors is not really hard as yanick demonstrated by porting XPathScript to Apache2::TomKit (http://search.cpan.org/src/YANICK/XML-XPathScript-1.45/lib_tomkit/Apache2/TomKit/Processor/XPathScript.pm). > AxKit2 was born out of my desire to build a perl httpd that scales, plus > build the AxKit2 that I wanted given my experiences with AxKit1. It > ended up that what I really wanted was a trivial way to say "Do some > XSP, then some XSLT on the result" and "Cache this thing", but in perl, > without any magic. This was also my intention no C-Magic, ... . Most distribution come already with an apache with mod-perl enabled. Apache2::TomKit is running everywhere mp2 is available which means >Apache-2.0.49 and Apache-2.2.x with all mod-perls released after the namespace switch (sorry RHEL customers). The main reason for me to provide Apache2::TomKit on top of MP2 is that one day I want to use Apache2::TomKit as the presentation frontend to an Content-Management-System of my choice even if it's written in php, python, perl, ruby, ... . > > The beauty of this approach is that I figure it won't be long until > someone comes along and builds an AxKit1-a-like using the AxKit2 API. > But hardcore users will still have the low level stuff to make it do > what they want. > > Hope that helps. Feel free to ask more questions. > > I think AxKit2 and Apache2::TomKit coexists nicely together where both have the same focus see Matt's and my intention to create AxKit2 and Apache2::TomKit. That's why we are discussing all aspects also in this mailing list at least this was the consensus the last time we discussed it and I think this hasn't changed. Tom
signature.asc
Description: PGP signature
