Ok, you perl people are aweful about this… Us PHP people are a close second…

Hold on, rewind, let me begin again.

There are two kinds of modules which attach to scripting languages.  Compiled, and interpreted.

A compiled language module is something written in another language (commonly C, C++, or ASSEMBLY) which “plugs in” to the scripting language to give you, as the scripter, new functionality.  The MySQL database connectors are a good example of this.  MySQL provides an interface to the version of the MySQL server currently installed via a C based API.  PHP and PERL both have modules which “wrap” this API up and provide us with neat clean little functions to work with in our npreferred environment.  You would do something like this for a couple of reasons.  Most commonly the reason is performance: It’s simply faster to do some things via certain languages (which might not be the one(s) that you prefer to work in.)  Second is availability.  If something is particularly complicated *or* not publicly available, you would build a wrapper around a vendors API just for the convenience of not having to write your own.

An interpreted module (or library) is written in the language that you’re using.  It’s simply there to provide you with more complicated functions that have already been written (many of the CPAN and all of the PEAR modules fall into this catagory.)  This is *just* like you writing a function in your language and then re-using it elsewhere. There’s no real magic here except that you didnt have to do something yourself.

Compiled modules carry with them the burden that all compiled programs share… including machine architecture and software environment dependencies.  What this means is that a module compiled on machine A will only run on machine B if they are set up in the same way with the same hardware.  If they *are* all the same, then this rant applies to compiled modules as well.. if the environment is *not* the same (because of a bad sysadmin, poor funding, or legacy hard/software) then compiled modules *should* fall into the domain of the sysadmin.

Because interpreted modules are like the libraries you write yourself and reuse over and over (and if you dont then you need to think long and hard about your development model, because its not as efficient as it should be) they can be installed in two ways: globally, and locally.

Globally installing a software module is, basically, just putting it into a place where any piece of software running that language can simply include the file by calling the proper command, and code with the provided functions.

Locally installing the module is putting the module itself into your application and calling it via an include in the same way you call any other library which you’ve already written.

Now let me say that if you A) have a development team, B) have multiple servers, and C) have a complicated environment requiring lots of modules for your web applications to work properly you have no excuse for not having some sort of version control system which gives you a central place from which to check out and update the code which runs on the servers.

Ideally updating the application across X number of web servers would be something as simple as “svn up”.  Period. No, really, thats the end of it.  If you limit your module use to software modules, and install your software modules into the application (as part of your repository) you have complete control over your web environment!  No more “damn sysadmin… if *I* were in control of these servers dot dot dot (…)”  Why arent you in control of your web servers? If you write your applications properly the only thing you should need is a server with the base tools you can be in crontrol.  That way you can leave the admin to do the things he’s supposed to be doing: security work, building you more servers, and generally improving the stability of the platform on which you run your apps! But the benifit is not just for the sysadmin!  If you find that you need the latest X+ 0.00000002549 version of module XYZ you dont have to wait for anybody to install it for you. just pop it in, and update your repo, and distribute. Ahh, scalability, and control!

When the development team works with the ops team something happens that truly deserves a buzzword like “synergy”… when they work at odds against eachother… well… Who wins in that case?  Good question.  Go ponder it.

Cheers

DK