At 05:36 PM 10/28/2001 +0200, Robin Berjon wrote:
>On Sunday 28 October 2001 15:58, Gunther Birznieks wrote:
>> I think the list is basically reasonable. Although I think that template
>> systems is tough to put into the P5EE category. It is in J2EE because of
>> JSPs so tightly coupled to servlets. But with the numerous template
>> technologies out there for Perl, I would prefer to put it into it's own
>> category -- perhaps within interfaces.
>
>Imho templating systems have to be out of P5EE if only for political reasons
>:) We all know for a fact that as soon as we're going to try to fit one into
>the framework no one is ever going to agree on which one to choose, and P5EE
>will split into tiny bits and die in flamewar.
>
Hi,
This thread of discussion has caused me to reflect on two emerging visions
of what the P5EE is all about.
My vision of P5EE is expansive and diverse rather than
the limited and standardized vision seemingly held by Robin, Gunther,
and Paul.
I propose that we can accommodate both visions if we can develop the right
vocabulary.
My vision is consistent with the view that the mission of the P5EE is
generally
to promote the development, deployment, and acceptance of
Enterprise Systems written in Perl
I think the following two elements support this mission.
* Expansive - specify everything possible that presents a consistent
Enterprise Perl Architecture rather than limiting the P5EE
recommendations to a limited set of politically acceptable choices.
i.e. specify a template system, a persistence layer, etc.
This will include many decisions which make up one great way
to do Enterprise Perl Development without having to be the
"only way" or the "standard way". This will be helpful to people
wishing to develop Enterprise Perl Systems.
* Diverse - The only way to be Expansive and not "exclusive" is to
accommodate a diverse set of views on what the full enterprise stack
looks like.
The opposing two elements are:
* Standardized - specify only what components that everyone can agree on
* Limited - the result becomes a subset of even what J2EE proposes, which
in my opinion, is far short of the support we could provide to
Enterprise Perl Development.
Now some have suggested (Gunther?) that we distinguish between (1) what is
a part of P5EE, and (2) what is P5EE-enabled. This may be semantically
equivalent to saying that the "Limited/Standardized" vision is a subset
(perhaps growing over time) of the "Expansive/Diverse" vision.
However, this seems to indicate that the "Expansive/Diverse" vision does not
have a place under the aegis of "P5EE" or in the P5EE effort.
This, to me, is why the discussion of P5EE's mission is so important.
It resolves questions like this. And the mission I am operating under
(because no one has proposed any other mission statement or given
compelling reasoning for it) leads me to believe that an Expansive/Diverse
vision is appropriate because it would be helpful "to promote the
development, deployment, and acceptance of Enterprise Systems written in
Perl".
I propose that both of these visions are compatible with some vocabulary
such as the following.
* P5EE - any extensions (doc+code) that promote the development,
deployment, and acceptance of Enterprise Systems written in Perl
(i.e. the P5EE aegis covers both of the following)
* P5EE Core Modules - (Limited/Standardized vision) the set of core
modules widely agreed on my Enterprise Perl Developers that are a
part of Enterprise Perl Systems.
* P5EE Blueprints - (Expansive/Diverse vision) (note the parallel to the
concept of the J2EE Blueprint, http://java.sun.com/j2ee/download.html)
Details describing good ways of implementing Enterprise Perl Systems
on top of P5EE Core Modules. (May include many more details than
are strictly relevant to Perl.)
* P5EE Optional Modules - (bridge between the two) sets of modules
which are part P5EE Blueprints which are beyond the P5EE Core Modules.
Stephen
