At 08:31 AM 10/26/2001, brian moseley wrote:
>On Fri, 26 Oct 2001, Gunther Birznieks wrote:
>
> > P5EE should be about getting a good solid minimum API that basically
> > doesn't attempt to do too much more than J2EE. At some point I believe it
> > is good for Perl if we throw away diversity for some key core APIs, but we
> > should, as much as possible, promote diversity that is part of Perl's core.
> > Application-level frameworks is where I would draw the line and say that I
> > expect as much competition as possible.
>
>on the other hand, web applications would benefit from some
>standards as well. the java servlet specification mandates
>the web.xml file with certain contents, which requires
>servlet containers to provide a particular set of
>functionality. whether the application framework is
>openinteract or extropia or wombat or what have you, it
>would be really nice for web application DEVELOPERS to be
>able to rely on a single api for sessions, authen/authz,
>logging, etc, whether or not they use mason or tt or
>whatever. it would also be really nice for application
>DEPLOYERS to be able to rely on a single application
>directory structure, config file, application library
>location, war file format, etc. just as cpan and makemaker
>force us to use certain conventions in order to provide
>great benefit, webapp specs could potentially make
>application work much easier.
While I think it is "nice" for developers to rely on a single API,
sometimes these things aren't so cut and dry due to the language design of
Perl as well as the rich history of Perl.
Java has to have a servlet API precisely because it's so shitty at being a
CGI script. Perl has always been more flexible in the "average spaces" like
guestbooks and the like than Java has been.
It's quite telling that Perl has included CGI.pm as a core part of the
language distro for some years. But Java still considers web application
support an "enterprise addition" to the core Java SDK. This is perhaps
reasonable because servlet developers have to have a certain level of
expertise. The ability to program Servlets in Java is kind of like teaching
a Perl programmer to bypass CGI entirely and go straight to mod_perl which
isn't necessarily a very intuitive evolution.
I think it's reasonable for Wombat to be included in P5EE officially as an
answer to J2EE, but I don't see it really taking off in the same vein as
SOAP, a transaction engine, and/or messaging engine part of J2EE for two
reasons:
1) The libraries that exist to do web applications programming and
frameworks to do so are already quite numerous. I
It's hard to believe (although not impossible) that they will move to using
a servlet API as it adds extra overhead to things that already arguably "work".
2) I guess that in order to make it reasonable to use a servlet framework
in Perl, then it can't be mod_perl only. It has to also support CGI and it
has to do so without a great deal of extra overhead (or the CGI developers
will find it more lightweight to use something else). Ideally it should be
at minimum lighter weight than CGI.pm.
Anyway, again, since J2EE has a servlet API, I think it will be useful to
have a servlet API in Perl for P5EE if nothing else than to provide a
starting point. However, I don't necessarily believe in it as the API that
a lot of people would just want to use for their application. This is a
cultural, time, and technical issue that will take a longer time to resolve.
Later,
Gunther
