At 01:08 PM 11/8/2001, Perrin Harkins wrote:
>I've been holding my tongue so far, since I don't have programming time
>to commit to this project right now, and I also don't feel the need for
>it as strongly as others do. However, I wanted to make a few general
>responses to what I've seen posted so far.
>
>I don't think it makes sense for P5EE to be a TMTOWTDI thing. CPAN
>basically *is* the TMTOWTDI version right now. This project will only
>be useful if it results in something that provides sufficient
>hand-holding to quiet management fears that Perl has no coherent
>strategy for building serious applications. I think this is in no small
>part what J2EE is about.
I think this is correct if you are talking about a P5EE wrapper API, but I
also think that documentation is still quite reasonable. ie Documenting the
current items of CPAN that can be used to duplicate a P5EE system.
>Note that there's nothing to prevent people from using what they like
>and replacing the rest. Many of the big name sites on Sun's J2EE list
>are using little more than the servlet API from the J2EE package,
>preferring proprietary stuff for the rest. If the pieces of P5EE are
>reasonably orthogonal, this shouldn't be a problem.
>
>It follows from this that there needs to be a suggested way to build web
>sites. I can't see CGI being it. Maybe an abstraction layer like
>Brian's libservlet could work, since it can theoretically be ported to
>CGI, mod_perl, FastCGI, PerlEx, etc. It's clean and consistent, but
>something about directly copying the servlet API creeps me out a little,
>and it sort of looks heavy compared to ultra-fast stuff like
>Apache::Request and Apache::Cookie. Maybe there's a way to Perl-ize it
>a little more.
I don't know if this is actually correct for Perl that it requires an API
orthogonal to servlets as "the way" to building web applications in Perl.
However, with that said, I think a way of making it possible for web
applications to easily port to other environments has merit.
However, I am not sure servlet API is the way to do it. If we were to do it
as a Perl way without prior precedence from Java, then the most accepted
API is CGI.pm. Thus, thin wrappers should rather exist around
Apache::Request and Apache::Cookie that emulates the CGI.pm API. Likewise,
if someone using CGI wants a CGI-Lite, it would do everything CGI.pm does
now but smaller.
Session handling is the next most major thing that servlets give you.
Apache::Session should be morphed then into something that is more
comprehensive (such as Servlets offer). Everything else about servlets is a
bit of icing on the cake.
If this were a purely technical merits discussion, I would say we should
throw away the servlet API in favor of the Perl-isms that exist. But as
this is also an attempt to make things orthogonal to Java, Servlet API
would take precedence I think.
>This system hasn't become as popular as I thought it would, and I wonder
>if this isn't because the average Perl hacker is simply more drawn to
>the plug-and-play aspect of tools like Embperl and Mason. OpenInteract
>is more prescriptive in its programming model, and thus takes more
>effort up front.
If it's not considered "popular", it's probably due to the lack of
standalone application tarballs that are easily installed without having to
setup a mod_perl environment (which entails a certain level of expertise).
Most app engines try to organize themselves around being an app engine with
maybe a few demo applications. But at eXtropia, we organize ourselves as
applications which happen to use an app engine. I think the later is the
more popular marketing approach.
We have huge negatives in our approach, for example, you won't find any
eXtropia stuff on CPAN. Because we are application centric in our marketing
of the toolkit, we do not CPANify the applications. We could CPANify the
toolkit, but our greatest time is spent rather creating new applications
and releasing them rather than putting modules on CPAN.
I know CPAN is more recently becoming "application friendly" but it's
branded as being for Perl gurus and for downloading modules. It's not
branded as the first place someone goes looking for Web BBS or a Web Calendar.
Sorry about this digression. I guess it's probably blasphemous for those of
you who are more advanced users of Perl and can't imagine life sans CPAN.
:) Of course, P5EE should be a part of CPAN.
I am just saying why releasing an excellent module set does not guarantee
popularity as there is much more to life than CPAN even though CPAN is a
great community itself. It's just that there are more communities than just
the CPAN one as hard as that may be to believe.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
