Brian, you've been taking a beating on this thread. I don't want to add
to it, but you did raise a couple of interesting questions in this post.
> the availability of application server products in the java world is
> another example. go look at enhydra enterprise
> (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that
> something like that exists in the perl world.
Personally, I'm kind of pleased that nothing like that exists in the perl
world. It looks like a recipe for a slow site to me - complexity for the
sake of complexity. But I've been burned by Java "application servers"
before so I may be a bit prejudiced against Enhydra. I think the part of
server-side Java that has the most value is the basic servlet API.
Personally, I find it pretty easy to replicate those services in mod_perl
without doing any additional coding, but I know you believe it's still too
difficult for newbies, and you may be right.
Part of the problem then is that perl is all things to all people. This
thread has already covered both the "it's harder than PHP", which is true,
and the "it's not as polished as Java", wich is also true. Some projects,
like Embperl and Apache::ASP, have gone a long way to make the barriers to
entry lower for the PHP types. There has also been a lot of effort to
make more polished web pages and documentation for some mod_perl projects
lately, Mason and AxKit being cases in point. I doubt it will ever
compete with Java in this regard though, since no single mod_perl project
is likely to get the same level of promotion that a WebLogic can muster.
The mod_perl message will probably always be about choice, flexibility,
and source code.
> you don't have to spend time re-integrating Apache::Session and
> Apache::DBI and Apache::WipeMyAss with each new project.
I think Apache::WipeMyAss auto-configures as of 0.3. But seriously, do
people have that much trouble using these defacto standard modules?
Maybe they need some more work in certain areas if they don't function
correctly "out of the box" for most people.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
