Module::Build command line

For reference, this is how to override things on the Module::Build command line.

perl Build.PL --config optimize='-g -pipe'

I seem to recall discussion on the list that it’s going to be better documented in future releases (more end user specific). This will be greatly appreciated.



After months of neglect, I’ve picked up on XML::Genx again. One “A. Pagaltzis” wrote to me and made two suggestions. Firstly, why didn’t I wrap genxScrubText() and secondly why didn’t have a method for automatically creating XML output as a string since that’s such a common use case.

Well, I tried the first one and got very frustrated by XS and its little foibles. So I left the whole project alone for a while.

But last night, I started working on the string appender. And it was actually much easier than I thought. Not only that, it gave me the idea for making the internals much better and cleaner. At the moment I have an internal global hash, because I can’t store things in $self like normal Perl OO code (because $self is a blessed scalar point at a genxWriter instead. But genxWriter takes a user pointer, so I can just stick the hash in there. I shoulda thought of that ages ago.

So, one new release today and a cleanup release RSN to rework the internals around user data a bit better. And then I’ll get back to genxScrubText().


Servlets vs mod_perl

I’ve been looking at the Java servlets stuff for a couple of days now and it’s clear that it bears a remarkable similarity to mod_perl.

  • In mod_perl, you define handler() which gets passed a $r object to deal with the request and send a response. Servlets make things a little more explicit. You make doGet() or doPost() methods, which get passed separate request and response. But they’re basically equivalent to $r.
  • mod_perl and servlets both have filters, but they work in slightly different ways. servlets are much more explicit; you have to forward the call on to the next servlet when you’re done. mod_perl handles things nearly implicitly (with help from Apache::Filter).
  • mod_perl is exposing the apache httpd API so you get access to different request phases. servlets run in a completely different environment, so that just isn’t applicable to them.
  • Whats also incredibly similiar to both pieces of software is that most people think that they’re far too low level and have come up with higher level “frameworks” on top. The standard one for Java appears to be JSP, which on close inspection bear a marked similiarity to HTML::Mason. As with mod_perl though, no one framework covers everybody’s needs, so there are lots of similiar, competing ones.
  • One thing that’s markedly different between the two is deployment and configuration. Most mod_perl deployments tend towards the messy, unless the application is packaged up like a CPAN module. But configuration is always manually done. Servlets come with a nicely defined “deployment descriptor” (aka “config file”—they love big words in the Java world). In addition, there’s a standardised directory layout and packaging format making it easy to deploy your application. In theory. I haven’t actually got as far as deploying an application in a production environment yet, but it looks reasonable to me.