Results

Tomorrow is google's appointed 'firm pencils down' date. That seems like a good time to discuss the results of my work on mod_parrot so far.

mod_parrot is, as I have mentioned before, a two-layered system, with one half interfacing with apache (the module) and the other half with the interpreter and the compilers, the 'loader'. There is also a vital third component, the test system called pudding.

The module is separated in several parts, namely IO, interpreter management, request routing, loader invocation, module configuration and general utilities. This week I've worked to create a more flexible request routing infrastructure. While this is mostly successful there are still some bugs to work out; when this is done it will be merged back into master.

As far as loaders go, I believe I have implemented the two most relevant to modern web applications, namely CGI and PSGI. CGI is what you may now from the olden days of guestbook scripts, PSGI is instead a modern architecture for web applications. NotFound++ contributed a script he called hinxed, which scans a file for inline pieces of winxed code. Even though the concept is intriguing, I have not yet included it as a loader.

mod_parrot can currently run only in single-threaded multi-processing modules. That means it is pretty much limited to unix installations which makes these (relatively) efficient. This is because of the problems with running multiple interpreters on which I have reported previously.

Some things are also not yet done.

Proper error reporting is of vital importance to web programmers. mod_parrot currently does not support error reporting 'handlers', which I had planned earlier. Similarly, determining what file to serve based on a request, also known as routing, by script is not yet done (and unlikely to be done soon). The reason is that I have not yet figured out how to configure these specific handlers, and with what argument they should be run.

Bytecode caching doesn't exist yet, and neither does an installation script (although the latter is easy to write). Configure.pl should test for the presence of required libraries (libffi), which currently it does not. The big show (perl6) also does not run as far as I now know. This is quite possibly because of loading / initializing different libraries, which aren't linked by mod_parrot. This is something I have to investigate, but haven't due to being computer-limited.

mod_parrot cannot run filters, either, unlike mod_perl. That was in fact a conscious decision; I believe filters have a limited value. Interacting with them would have implied manipulating the bucket brigade structure, which is hard to abstract. Few people these days write code that is so dependent don a particular web server, even if that is the most popular server on the web.

The current test suite contains functional tests, i.e. they test the behavior of the system as a whole. As opposed to unit tests, which test the behavior of a part. I find functional tests to be highly effective as they allow the testing of relatively large changes at once. They do not depend on a particular architecture. For some things however, I wish I had implemented unit tests. Especially components of the compiling subsystem and the interpreter handling subsystem would have been relatively easy to test this way. Unit tests for the C programming language are relatively tricky, though.

Debugging the module was made relatively easy with pudding, which allows you to start a preconfigured server under gdb. This has given me easy access to extremely detailed debugging information. Coming from a mostly 'dynamic' background this was a very pleasant surprise. I should add the ability to specify the debug mode by an enviroment variable, rather than by editing the script. Pudding can also give you the error log after each script, by specifying the VERBOSE=1 variable.

Well, that was about all of my summary. I want to thank whiteknight for good advice, fixing bugs and being arround. And I'd also like to thank everybody else in the community. You have been patient and educative and I have learned a lot from it. I hope we can make good use of my small contribution.