At 12:10 PM 8/11/2001 -0400, Stephen Adkins wrote:
>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.)
The idea behind P2EE is not precisely new. Larry Wall addressed it in his
State of the Onion speech this year. Basically Perl 6 is the rewrite and he
realized the standard distro of modules is really both bloated and too
sparse at the same time.
So what may make sense is bundling stuff in the same way that Java does. So
in Java you have the standard SDK library of class files but you also have
the J2EE bundle.
>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
I think this is reasonable. Items for definite inclusion would be POE and
SOAP::Lite. I hesitate to include templating systems or application
toolkits. Although Caching (Cache::Cache, IPC, etc) could also fall under
P2EE I think.
Later,
Gunther
