Hi,

 * Can anyone suggest what mailing list I should go to in 
   order to discuss the creation of a P2EE specification?

Thanks,

Stephen

BACKGROUND

A discussion began on the [EMAIL PROTECTED] list which started with
discussing "CPAN pollution", i.e. the fact that there is so much
(1) bad stuff, and (2) redundant stuff on CPAN that it's hard to tell
what to use.  Eventually, references to CPANTS arose (which I
understand to be a somewhat organic, automated, self-regulating
rating system for modules on CPAN as well as a cross-platform testing
system).

However, I suggested that the solution that I was looking for was not
for ratings of individual modules but for specifications on how to
build enterprise systems using Perl and which set of modules to use.
This is similar to what J2EE did to the collection of maturing Java
packages which were growing up at the time.  I proposed that such a
specification might be called P2EE (see the post below).
(Someone mentioned that Larry Wall had made a reference to P2EE in
his 2001 State of the Onion 5 speech, which I searched for put could
not find the full text of anywhere on the web.)

The discussion thread had long gone off-topic at [EMAIL PROTECTED],
and I was referred to [EMAIL PROTECTED]

I read the archives and I see that you have essentially been discussing
the creation of a single list of "core" perl modules to be included in 
a package called the Perl SDK.

What I was proposing was different.  See below.

Can anyone help point me to an existing mailing list discussing
something like this?

>Hi,
>
>At 04:42 PM 8/11/2001 +0200, Elizabeth Mattijsen wrote:
>>At 09:26 AM 8/11/01 -0500, Jim Smith wrote:
>>>If we want better QA, I'd propose requiring approval from someone on that
>>>list before a module is put anywhere in the heirarchy other than the
>>>author's directory instead of only requiring approval for a top-level
>>>namespace.
>>
>>Are you aware of the CPANTS initiative?  Michael Schwern gave an 
>>interesting talk about that at the YAPC::Europe.  See e.g.
>>
>>  http:[EMAIL PROTECTED]/msg00148.html
>>
>
>I like the idea of CPANTS, karma, kwalitee, etc.
>However, another approach is similar to what J2EE did to Java.
>There were lots of libraries/packages growing up in Java, and the
>J2EE spec said "these versions of these API's make up a consistent,
>extensive, useful, architecturally sound platform on which to build 
>applications".
>
>What about the concept of a P2EE specification?
>(P2EE is pronounced "pitooey", as in "I spit on the notion that 
>Java is the only language for enterprise-capable web application 
>development". It is also pronounced "pee-two-ee-ee" when managers 
>are around and you want to convince them it is a legit technology
>for your next project.)
>(I also note that "p2ee.org" is not yet taken as a domain.)
>
>We all know that there will never be a single P2EE specification.
>This is because there will be those who think that one template system/
>data persistence layer/XML Library/etc., combination is better than another.
>
>However, individual perl gurus could pull together their list of 
>consistent, complementary, and quality API's/modules (and how to 
>use them) in a spec and call it their vision of P2EE.
>
>This would be very valuable to those just getting started.
>They understand that There's More Than One Way To Do It 
>(tmtowtdi), but at least they can survey how various perl gurus have 
>integrated the many different technologies before them and learn
>at least One Good Way To Do It from each spec.
>
>This method of competing P2EE visions
>
>  * is decentralized and dynamic (not centralized and unchanging),
>  * is merit-centric (P2EE visions will wax and wane based on merit), and
>  * provides a way that individual modules can rise above the crowd.
>
>I can envision that module authors would work with the leading P2EE spec
>authors to ensure that their modules fit into the vision.  If the P2EE
>spec authors like the modules, they get included in that particular spec.
>In this way individual modules are naturally subjected to a certain form
>of peer-review in order to qualify for a spec.  In return, the visibility
>of the module is increased because of the spec.  If someone doesn't like
>the existing P2EE specs, they can create their own.
>
>Perhaps the various P2EE specs could be supported on CPAN with Bundles.
>
>I also think it would be *much* easier to rate/rank P2EE specs than
>individual modules on CPAN. (i.e. this goal is attainable with a finite
>amount of effort)
>
>Thoughts?
>
>Stephen
>
>

Reply via email to