On Tue, 5 Dec 2000, Perrin Harkins wrote:
> 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.
a beating? i don't think so at all, it's been one of the
most restrained threads on this range of topics in a long
while. and judging from the amount of personal mail i've
gotten, a lot of people seem to agree with me! :)
> 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.
cool, you should get a lot of use out of AO then :) i
definitely understand your viewpoint, and i realize that
there will be a lot of people who don't need the kinds of
things i'm proposing. but there are also a lot who do want
these types of components, and they really don't have any
options.
> 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.
eh, there's a perl infrastructure support/services company
waiting to happen. i just personally don't have the
motivation to do something on the scale that i think is
necessary. maybe this discussion is giving others ideas,
tho...
> 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.
i think a lot of it is that they are all configured in
different ways, and you have to write glue code to tie them
all together. a good example is the stuff you have to do to
configure mason. dave's implementing apache config
directives for some of that, which i think is a good step,
but i personally don't like having the configuration of my
application mixed up with the configuration of my web
server. so one of the things that AO has is a nice flexible
configuration system which allows all these various knobs to
be tweaked in one place, with no code writing. the net
effect is that it's extremely simple to clone a template
servlet app, spend 30 seconds tweaking, and have a running
app with authen and authz, session persistence, logging,
etc. it's all the same glue code shit i used to write for
each of my projects, now it's reusable and packaged up
neatly with a bow tie. rad.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
