This has been a really interesting thread. I would like to contribute my
own experiences as I am currently sitting on both sides of the fence.
--------
In my spare time, what little there is, I operate a web hosting service for
NZ Christian churches, organisations and ministries. This endeavour also
operates as a ministry and hence comes under some very real constraints, the
biggest being a very low budget. I can not afford to run top-end servers so
must make the best of fairly modest equipment. I can not afford to hire
programmers, so I do all the system admin and programming myself. I opted
for Perl as I was reasonably comfortable with it and wanted an environment
where I could build what I needed quickly and it would be relatively easy to
look after. In the early days, I used to pull my hair out trying to get
each new release of apache and mod_perl running, the problem was usually
compounded by adding SSL. The arrival of Ralph's mod_ssl and the more
recent apache and mod_perl distributions have helped heaps.
What do I do with mod_perl, at this time it serves 3 purposes 1. It allows
me to use my PostgreSQL database for web authentication (AuthDBI), 2. It
offers database connection persistence, 3. It operates as a CGI accelerator.
I haven't needed to work directly with mod_perl but have some things I would
like to use it for next year. But my own site is only one of 150 odd on the
server and I am the only one using mod_perl, a couple of sites use PHP, why
? The simple answer is - I can. It is my environment and I have control
over the whole shooting match, I can fiddle the apache config as necessary,
I can easily add perl .pm's as needed. I am technically competent and used
to working with non-trivial technologies.
--------
I work in the IT department of one of NZ's Universities, I have been here
for years and consequently have watched and been involved with technologies
that have come and gone. The latest area that our applications people are
working with is using the web to deliver information from and interacting
with our student management system, a large Ingres Database. The current
application is run as a CGI and is written as a monolithic perl programme.
Simply put, it is a disaster. The people who wrote it, learned perl as they
went, and being fair to them, it works. Their architecture enabled them to
add functions reasonably quickly, but the application does not scale. They
are not using any database connection persistence at all and multiple
concurrent session very quickly kill the web server, a high-end Compaq
alpha. This application has seen us through the last 12 months but is
hopefully to be replaced. With what ? Well, it would seem that no amount of
arguing by the systems programmers or myself is going to be successful in
getting them to continue with perl, but in a mod_perl environment. They are
going to go the Java way, the reasons have all been stated in this thread
before; Market hype, its an expensive solution so it must be good, its a
cool new technology, you can't get good perl programmers, its what is being
used by everyone else, we don't understand mod_perl ( they don't understand
the java solution either ), we can buy the business logic we don't have to
build it ...
--------
I like the perl/mod_perl solution, it works well for me, I believe it is
also an appropriate technology for solving enterprise problems. The biggest
hurdle we have faced in trying to get it considered has been market
perception. If we had been able to find recognised or well-known
enterprise/corporate/large site implementations to use as reference sites,
it might have helped. To be able to say that site XXXXX uses a mod-perl
solution and they are using Ingres/Oracle/Sybase or whatever and getting
umpteen thousand hits a day gives the technology creditability. The
Microsoft and Java marketing machines have given their technologies
credibility (whether they deserve it or not is irrelevant).
The decision has been made, unfortunately, so much of this is now water
under the bridge but a list of reference sites might help others construct
better cases for their management.
--
Glen Eustace, Systems Engineer - Networking.
Information Technology Services, Turitea, Massey University, Palmerston
North, NZ.
Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
