Hello Matt and all others, I only wanted to put my 2ยข in here. First of all its great that there's something going on with AxKit. Having said that I hope you don't mind if I don't go along with your decision not using Apache-2.x/mod_perl-2.x but shiping your own httpd.
1. ties of Apache upgrade cycles -------------------------------- First of all I think the only problem with porting AxKit-1 to Apache2.x are the parts written in C because for those you need Apache-Core knowledge but because you decided to write the whole AxKit-2 in pure perl I can't see any problem porting it e.g. to Apache-X.X in future. Mod-Perl and Apache-Setup wasn't really the problem most of the time XML::LibXML was the beast (e.g. on red-hat) 2. easier to use and install in these days ------------------------------------------ As you already stated as an answer to a question you can't live without Apache at least as frontend-proxy in future. So you need to setup Apache and you contradict yourself ;-) I for myself see the situation like the following: - use proven thoroughly tested components (nothing against your perl-httpd-server) but is there anything better out-there? - reuse of many different modules already available for mod-perl this contradicts your reason no 1. because you need provide a layer in AxKit2 emulating mod-perl behaviour and then you definately have to adjust AxKit2 everytime mod-perl changes an interface even not one AxKit2 uses but any module designed for mp2 people rely on One more thing I think is that there isn't any offical statement how your decision to take this way for AxKit-2 is found anywhere. - Has it been discussed any where? - What do other developers think, do they go along with you? At least in the mailing lists nothing about this can be found. The thing I always loved about opensource development was that the decision-making process is open to anyone and it's not a secret in an Apache-Software-Project. I hope my cirtism did get too rough once more I appreciate your efforts but I wanted to let you know what I think. Tom Matt Sergeant schrieb: > Well every once in a while someone still asks about AxKit 2. I know this > project has mostly floundered and people have gone on to other things, > but I still find some value in the XML paradigm for web development - > specifically in saving me from worrying about XSS errors, but also it > looks really useful for AJAX stuff. > > Anyway... Where is AxKit 2.0? > > Well it's coming. In the last few days I've thrown together a few bits > of code that are the framework for AxKit 2.0. > > First things first: AxKit 2.0 is nothing like AxKit 1. It doesn't even > remotely resemble it. That's both a bad thing and a good thing. I'll > explain why. > > But first, what does it look like? Well I spent a long time thinking > about what it meant to be AxKit, and I also spent a long time thinking > about how could I make it easier to use and install in these days of > quick setup frameworks like Ruby on Rails. Sadly mod_perl is not quick > to setup. Neither is Apache. These are large complicated frameworks with > lots of features I don't need on my application server. Instead, AxKit2 > has its own httpd. You can read a bit about it here: > http://use.perl.org/~Matts/journal/30438 > > Having our own httpd means that development and deployment is much > easier. Plus it frees us of the ties of Apache upgrade cycles and > mod_perl changes. I did not want to be stuck for an "AxKit3" when Apache > 3.x comes out! > > So I wrote a simple pluggable scalable httpd. It's all pure perl, so no > nasty compilation required (except obviously you still have to compile > XML::LibXML etc). Plugins can trivially add configuration directives, > making development of new subsystems fast and easy. > > And yes it's buggy as all hell right now. But it'll get better I promise. > > Now, on to what the "AxKit" part looks like. Well I decided that I'd had > enough of special cases and extra wrapper code inside the AxKit > internals - we spend so much effort in there making sure dependencies > are logged and checked, and caching is done at every step of the way and > so on. All this actually slows the whole thing down, and makes the code > really ugly. So it's gone. If you want to cache from now on it will be DIY. > > And all that config directives stuff to setup pipelines - that got > really ugly if you wanted alternate pipelines. So that's all gone too. > Instead AxKit becomes an API for setting up the transformation > pipelines, and a bunch of utility modules for helping that out. Everyone > can write perl, and if you can't the examples will be simple enough, or > someone will write a plugin to set all this up via config directives. > > So let's do a quick example. Say you want to do XSP -> XSLT -> XSLT -> > HTML. Here's what the code you'll write will look like: > > sub hook_response { > my $self = shift; > my $file = $self->{headers_in}->filename; > > # setup the processor > my $proc = AxKit2::Processor->new($file); > > my $s1 = "/path/to/xslt1.xsl"; > my $s2 = "/path/to/xslt2.xsl"; > > # run the transform ($out is an AxKit2::Processor also) > my $out = $proc->transform( > XSP => XSLT($s1) => XSLT($s2) > ); > $out->output($self->client); > return OK; > } > > (Note: I haven't got XSP working yet - but it shouldn't be too hard, > touch wood!) > > So now where is this groovy code? Well it's in axkit.org svn for now, > but at some point I'll get the apache guys to setup a new repository for > us on there. Meanwhile follow the progress and have a play around at > svn://axkit.org/axkit2 > > Matt. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
signature.asc
Description: OpenPGP digital signature
