Front page | perl.p5ee |
Postings from September 2002
Re: kick-starting a new focus for P5EE
From: Stephen Adkins
September 23, 2002 12:42
Re: kick-starting a new focus for P5EE
Message ID: email@example.com
At 06:36 PM 9/23/2002 +0100, Greg McCarroll wrote:
>* Stephen Adkins (firstname.lastname@example.org) wrote:
>> At 12:57 PM 9/20/2002 -0400, Stephen Adkins wrote:
>I'm not sure that smaller focused groups are the way to bring about
>P5EE. First of all I believe that Perl already has P5EE it just needs
>a light layer ontop of many CPAN modules and a bit of marketting. Now
>while it may seem like a good idea to split each of these layer
>writing groups into seperate groups there will be so little work to do
>in each layer group (if they are writing functional code that isn't
>simply doing wrapping then they will only muddy the waters of P5EE)
>and they are going to face a lot of similar issues such as how you
>reflect level of compliance of implementation modules.
It is far from simple to:
* document an enterprise application architecture for enterprise systems
written in perl using existing CPAN modules (there are hundreds of
design decisions to be made even after modules are selected)
* write glue code that ties it all together
* support and receive feedback from a user community to tune and evolve
If you think differently, I would guess it is simply that you have a
different goal in mind of what should be accomplished than I do.
For instance, I could easily say, "This is P5EE"
* Apache/mod_perl - web application container and SOAP container
* Template-Toolkit - web user interface template engine
* Alzabo - RDBMS access on top of DBI
* What about other web servers? (IIS? Netscape? ...?)
* What about non-web-based clients?
* What about information not stored in relational databases?
The enterprise application architecture I envision will support
clients on any and every platform in the enterprise, and web
applications implementable on all of the specified platforms.
It will describe how and to what extent the architecture can
support all of the specified enterprise requirements.
Individuals and companies have solved these issues sufficiently
for their particular applications. Where is the description of
the generalized framework?
If this were simple it would have been done by now.
>However I realise we may have different views on this, so if you disagree
>lets discuss this ...
>What do you think that can be achieved in smaller groups that can't be
>achieved in this group. What problem(s) do you think the smaller
>groups fix that this group has? I'd appreciate a one or two paragraph
>answer on this.
I think a more appropriate question is
* What (at all!) can be done in a single, large group?
So here's the brief answer to your question.
Q. What problem(s) do you think the smaller groups fix?
A. Smaller groups can reach the level of unity necessary to get
something (anything!) done.
The longer answer follows.
I make the following observations.
* The perl community is highly fragmented, with many good solutions
to nearly the same problems. And people have loyalties to those
solutions because they know them and have invested their time and
energies in them.
* There is not a single source that I have ever found for how to
write enterprise applications in perl. The focus is on modules
and small distributions, not how to integrate them into a system
with enterprise-quality attributes.
* A working piece of code or an existing piece of documentation
(albeit with limitations or imperfections) goes a lot further
than the most grandiose theory created in committee.
In light of this, I proposed about a year ago that the people who
know most how to do enterprise application development write up
competing specs of how to do it.
In general the reaction to this was that it would be more desirable
to have a single set of code that we could all agree on.
Although I agree that this would be nice, I have always believed
that it would be competition among reasonable alternatives that
would bring any winner to light.
So the consensus was to work for a common code base.
People on this list engaged in much discussion about what enterprise
application development was and what the good modules were and
I catalogued those (albeit imperfectly) in my Components page.
Then I set out to create a framework that would make the most people
happy by providing flexibility to use whatever template system or
persistence engine or configuration file format they chose.
No one was happy with it.
This approach could not really get any kind of ringing endorsement
to move it into the P5EE namespace. (Even though it did get a
majority of votes, the dissent was significant enough to signal
that the people on the list are not ready for any kind of
common code base. It must be proven in implementation first.)
So I conclude that the most that we (as a group) are ready for
is a shared discussion area.
But some of us are ready to move beyond that.
The fact is we are already many small groups (individuals, in
fact). Discussion on the list has already shown that there is
insufficient unity of purpose or direction to achieve what most
of us wish someone would do.
Suppression of small groups forming is to inhibit the progression
of thought toward our goal of One P5EE (if that is even ever
I intend to make this project support whatever size groups
will be effective in achieving the advancement of enterprise perl.
>> I'll be proceeding with
>> this plan and recasting the P5EE web site in this new light of
>> "P5EE diversity".
>I hope you after this email you'll take time to discuss the matter
This plan is the result of all of your input.
It is the logical conclusion of discussions and votes.
No other plan has emerged that will get us going.
Anyone who wants any other outcome suggest a better plan and
be prepared to get involved to work that plan.