I'd be curious to know how this is working out as we already have something
similar and have been working on it for a couple years in evolution where
Java Servlet compatibility was a key (but I'll admit -- not a #1) component
to our design process.
The stuff we've done emulates servlet architecture as greatly as we felt
was possible without
(A) forcing anyone to use a particular templating language (ie JSP style)
although I have to say that I really liked Matt Sergeant's Perl-style XSP
layer in AxKit at the conference. We've really started growing used to the
JSP template model and so, seeing it implemented in Perl (Albeit more
powerful for XML) was very interesting.
(B) performance (this is a key component that Perl doesn't do well if
forced to do everything servlet-style etc.
(C) Not forcing Perl users to use a method call convention that is
inconsistent with Perl.
eg It's making our session wrappers around Apache::Session that emulate the
Java Servlet Session API was OK because it's an external class. But IMHO
emulating an event driven doPost and doGet method that needs to be
overridden is a bit of overkill and we found confusing to our community of
developers that are used to CGI.pm syntax. Why force them to switch?
It emulates the architecture so closely that it took us only a couple
months this summer to port nearly all the object interfaces, some
significant drivers and have converted one of the hardest apps in Perl into
Java Servlets <-> Perl. In Perl we have many apps in production, but in
Java, we have one app (which we felt was the most representative to convert
first).
Now that we have the Java Servlet behind us, we believe every subsequent
Perl app we do in our current architecture will take very little time (days
to weeks depending on complexity) to switch over to Java based on
real-world experience. And vice versa. With most of the work being the
Views (which are View objects in our Perl architecture and JSPs in Java)...
Ultimately we'd like to move to View objects just being taglib controllers
for a template language.
Not surprisingly, things that were easy in Perl, we had write stuff for in
Java. So actually the same thing could be said of Java -- that Java people
would really enjoy a Perl way of doing things if given classes to do so.
eg in Perl, Perl Code can = Config File. But in Java, you really need
something nicer like an XML based config because no one wants to download
an app and have to recompile a Java class to set it up. Setting properties
in a servlet engine sucks because there are effectively over 300 properties
we allow setting (with many defaults) in WebDB. And placing them in a
singleton sucks because you want people to be able to run different apps on
the same web server without having to have multiple copies of the app.
Both our Perl and Java use a framework similar to those discussed in the
two main Apache.org Java servlet framework projects:
http://java.apache.org/turbine/model2+1.html and
http://jakarta.apache.org/struts/index.html
At 01:33 PM 11/1/00 -0800, brian moseley wrote:
>On Wed, 1 Nov 2000, Matt Sergeant wrote:
>
> > On Wed, 1 Nov 2000, Marc Spitzer wrote:
> >
> > > what is AO?
> >
> > A port of the servlets architecture to mod_perl.
>
>from the original announcement i sent on 4 sept 2000:
>
>README snip--
>
>AO is a servlet engine for Perl. It provides an application
>environment with such features as session tracking and
>persistence, security (authentication and authorization),
>simple configuration, and customizable logging. It also
>eventually will implement a Perl version of the (Java)
>Servlet API, providing applications with a well known model
>for application construction that abstracts the process
>model and deployment environment away from the developer.
>
>--
>
>AO integrates out of the box with Apache::Session and Mason.
>i'm hoping others will add integration with AxKit,
>HTML::Template, Embperl, ASP, etc. the plugin architecture
>allows for us to provide even more implementations of
>session tracking and persistence, credential checking, role
>authorization, etc, or even to replace the core subsystems
>themselves. the adapter architecture will eventually allow
>us to run AO apps in either an external perl process or
>using today's in-process model - without modifications
>either way. the addition of the Servlet API will add a
>featureful, robust interface to the web application
>environment provided by the servlet engine.
>
>this is my first release of AO to the outside world. it's a
>pre-pre-pre-developer release; much is unfinished or in need
>of rework, altho i am using the engine as is for several
>projects today. i'm interested in feedback on both the
>general goals of the software as well as on its architecture
>and implementation. there's no mailing list, so please
>either send mail to me directly or to the modperl mailing
>list (preferred). PLEASE read the README before you do
>anything else.
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
