Having talked to Leon in the past about "p5ee" I thought I'd help kick
off this list with some of my personal opinions about what p5ee should
be and what it shouldn't be. I'd say that my thoughts are more
"marketing" orientated than Leon's, but we see a lot of common ground.
Anyway onto the matter at hand ...
P5ee should not be a 100Mb+ tarball with Perl and every module we can
think of from CPAN that could be regarded as useful for the
enterprise bundled. This would achieve nothing but burn up some
bandwidth. CPAN should be used in a p5ee initiative, but I'll speak
more about that in a bit.
It should not be aimed at replicating j2ee, j2ee is already here so to
aim for what already exists forces us to play catchup. In fact Sun are
rapidly trying to reposition j2ee (and almost every other software
based technology) to compete with .Net. Also Perl is not Java, so a
copy would not work.
It should not be aimed at replicating .Net, .Net is a much wider
project than can be dealt with from a programming language initiative
(Sun do not seem to grasp this fact). However, p5ee should work with
.Net as well as many other infrastructure technologies as possible,
both open source, closed source and all the areas in between.
And there I've used the word "initiative" again. Now first of all I'm
not talking about a secret underground military installation to hunt
down vampires and python programmers, although that would be cool
(Apologies to people who don't watch Buffy the Vampire Slayer). But I
do think that an initiative is what p5ee needs to be.
First let me state what I think p5ee should accomplish,
It should be a weapon to help Perl programmers convince
technology managers and CTO's of the power of Perl at solving
the problems found in most enterprises.
A lot of CTO's already know Perl is a great hackers language, great
for getting jobs done quickly (and writing obfuscated code). However
when it comes to starting new large development projects, I think they
are reminded of the old phrase, along the lines of "Nobody ever lost
their job by buying IBM". They feel happier using Java, especially
with all the buzzwords attached to it, enterprise edition is definetly
one such buzzword - enterprise java bean another.
It is these type of projects that we have to demonstrate and document
Perl's suitability for and in some cases improve Perl's
suitability. It is almost essential that the later occurs, not due to
just the suitability aspect, but due to the fact there needs to be real
substance to this initiative, neither pure marketting/hype or pure
coding will deliver at least the potential of a sucessful p5ee
initiative, as with all of this post, its in my humble opinion.
Now, some good news, hacking up p5ee modules is fun due to the
interesting problems involved with things such as object persistence
and messaging. And In my experience "fun" stuff generally gets done
while boring stuff doesn't, so when we identify some new
modules/functionality we will see it materialise sooner rather than
later.
However a new set of p5ee modules will not really solve anything
unless they are "sold" as part of the wider initiative.
However, this is the boring/not fun part of the initiative so its best
we cheat. I believe we should grab some projects that are already
there and sell them under the p5ee banner. Things like the O'Reilly
success stories could be looked at, for stories at enterprise level and
these could be linked to from the inevitable p5ee website, another is
CPAN (There are probably others, but its best if we start with a
smaller target).
CPAN is one of the major strengths of Perl and we need to
better leverage this strength. CPANTS[1] and NAPC[2] are already doing
this, and they would be great projects to be part of the p5ee
initiative. If you wanted to be really cheesy you could add a
classification to CPANTS along the lines of "Enterprise Ready", which
would mean that the particular module is appropriate for enterprise
use. Whatever we do we need something like CPANTS to make the power of
CPAN for enterprise development more visible.
And on that note, its a good time to state that Leon sees one of the
major advantages of any p5ee initiative being standardised API's for
for enterprise modules. He cites DBI as the example. Now I tend to
agree with this, as it solves another itch I've had for some time with
CPAN and modules.
I believe that reinventing the wheel is not just a fun activity but
also a useful exercise - you never know when your going to come up
with a better wheel. However having 20 different wheels is potentially
a bad thing, unless there is a standard API for the problem spaces and
there is some form of quality control (e.g. CPANTS) for the various
modules, err I mean wheels ;-)
So as I already stated we cannot just look at j2ee, we need to figure
out what needs companies have from Perl and then sit down and work out
some API for each of these needs, object persistence, messaging,
authentication/authorisation, structured data access all spring to
mind, but I'm sure there are others. Once they are in place (the
API's) then we can retrofit existing modules into place with them and
write new modules that adhere to these API's.
It also allows better documentation/books to be written for each
problem space as you are comparing like with like and the
documentation for the API's should not change as much depending on the
back end.
With these new API's, backends, CPANTS/NAPC, sucess stories and
documentation we can launch p5ee and hopefully start to improve the
perception of the suitability of Perl for "enterprise class" projects.
Greg
[1] http://magnonel.guild.net/~schwern/CPANTS/
[2] http:[EMAIL PROTECTED]/msg00503.html
--
Greg McCarroll http://217.34.97.146/~gem/
