Puma
P e r l   U n i v e r s a l   M a r k u p   D o c u m e n t a t i o n
SourceForge.net Logo

Every good work of software starts by scratching a developer's personal itch
Eric S. Raymond - The Cathedral and The Bazaar

PUMA IN A NUTSHELL
Puma started out my personal itch to get an all-Perl equivalent to Microsoft's ASP. Even though there are a number of packages available that will do similar things (see Notes and Credits), none of them really scratched my itch in the way I really needed. I wanted something much more like Sun Microsystems's JSP/EJB/J2EE in structure, but I wasn't a big fan of Java (personal preference) and I found the J2EE architecture much too heavyweight and inflexible for the light and medium weight applications I'm used to implementing.
So what could I do? Live within the confines of someone else's vision? Not likely. Not for a stubborn ass like me. So I went and borrowed bits and pieces from here and there, tore them apart and reassembled them in the way I wanted. With the encouragement and input of some guru-like colleagues, I got Puma to the point of stability and usability so that I could manage to call it a first release. Then it was time to register it on SourceForge and hope that more developers would take the core and run with it.
As these paragraphs were written before I announced the first release, the jury is still out as to whether this will take off or turn out to be a dud. In all probability, it will be the latter: a red herring - a rather smelly, rotting, mostly dead red herring.
THE PHILOSOPHY OF PUMA
Puma does have a philosophy. No really - it does! It's not a grand philosophy, but it works.
The whole idea is to put together a stand-alone package, without a lot of dependency on outside packages that are not usually a standard part of the Perl distribution.
I am motivated to make this a part of the philosophy because, as stated before, I'm a stubborn, lazy ass. I hate pulling modules off CPAN and find out there are dependencies I have to fulfill. I then try to resolve those dependencies and there are further dependencies, and circular dependencies. ARRRGGGHHH!!!
So enough of that! That's one of the reason I went through the trouble of build the Puma::Util::XML module. I didn't want to depend on someone else's module for XML parsing.
Will I accept plug-ins that have dependencies? Sure, but there has to be a bold message warning of the dependencies in a monstrous flashing red neon sign attached to every distribution. That's all.
THE LAYOUT OF THIS DOCUMENT
This document starts with installing Puma on you Linux box. It then continues by covering a number of the major modules included in Puma, and finally does a bit of prognosticating about the future of Puma (if it has one!).
I also presume that you know Perl (OO Perl is especially useful) and have some exposure to the concept of in-line HTML programming markup in the form of ASP, PSP, JSP or something similar.
This document will NOT teach you anything about Perl aside from the fact that you will need to know it.
As this document is still being written, you will notice that there are sections that are incomplete. Be patient with me.
WHO THE HELL ARE YOU?
Puma is a development effort put together by nobody particularly important (that'd be me - Ingmar Ellenberger). Do I have impressive credentials? No. Do I care? Not really. Do I like my work? Absolutely.
My background in Unix and C goes back to my first job maintaining Unix systems in 1984 for a small company that collected and stored statistical data. It wasn't the greatest pay (I was still in high-school), but it did get me addicted on Unix and all things command-line.
After a number of years (I'm skipping the boring bits), I managed to snag a job in Seattle in the spring of 2000 as a Perl Guru (which I was not at the time). It was then I truly fell in love with the language in spite of some of the awful code that I saw written. It was about one year later that I started work on Puma, and another year after that that I finally brought Puma to first release.