Augmenting CPAN with P2EE specs, was CPAN polution

[Stephen Adkins <st...@officevision.com>]

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://archive.develooper.com/perl-qa@perl.org/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

[admin] OT tolerance (was Re: Augmenting CPAN with P2EE specs, was CPAN polution)

[Stas Bekman <st...@stason.org>]

Now, you realize that all this is drifting very off-topic, it's too bad
when people who are interested in modperl remove themselves from the list
because of the high volume of the off-topic threads, which people don't
even care to mark as [OT] :(

The topics are very interesting indeed, but please take them to the right
forums and let the list know where you take them.

The currently discussed topic may belong to these discussion forums:

CPANTS  : http://lists.perl.org/showlist.cgi?name=perl-qa
Advocacy: http://lists.perl.org/showlist.cgi?name=advocacy
SDK     : http://lists.perl.org/showlist.cgi?name=perl-sdk

and probably a few other lists that can be found here:
http://lists.perl.org/

Please move the thread there and tell us where so we can follow if
interested.

Also remember that your discussion of the offtopics is nice and
interesting, but it's usually a waste, because the thread will be
forgotten very soon. But if you discuss it in the right forum, you can
actually contribute a lot and help things happen.

We try hard to keep modperl list on-topic. I hope you realize that this is
very important.

Thanks for your understanding.

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide
mailto:stas@stason.org   http://localhost/      http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: Augmenting CPAN with P2EE specs, was CPAN polution

[kyle dawkins <ky...@centralparksoftware.com>]

Hi All

I was reading all the posts about people whining about the state of CPAN 
(as people should... it's hard to tell what's going on in CPAN these 
days ;-) and the topic has drifted to this "P2EE" thing that's getting 
thrown around.  I somehow feel vindicated:

http://www.geocrawler.com/archives/3/182/2000/12/0/4779413/


I posted that nine months ago when I got frustrated about the total lack 
of consistency, symmetry and homogeneity in Perl classes.  Even the shit 
that's built-in to Perl is a mess... who the hell wrote localtime()? 
Argh!  It's almost as bad as the java.util.Date fiasco.

Anyway, I am glad people are seeing that it's a problem.   When it comes 
to laying down standards, though, we have a few hurdles to jump... who 
decides who is in charge of these "standards"?  Perl gurus?  But more 
often than not, Perl gurus aren't "engineers", they're "ex-hackers", and 
I don't think hackers should be deciding what goes into P2EE...

But I think the basic idea of this "P2EE" --or whatever it's called-- is 
great.  I think things should be mandated everywhere like named 
arguments for methods, naming conventions for 
variables/methods/packages, coding styles.  APIs should be forced to be 
consistent across the board.  Methods should be named completely and 
descriptively (jesus h. effing christ i can't tell you how many times 
I've seen methods named "do_it()" and "process_data()"... are these 
people high?).  Methods should even be encouraged to describe their 
return value (like array_of_keys_sorted_by_name(%things) or something 
like that).  All of this comes back the basics of simple, clear 
programming to minimise bugs and maximise resources.  God, I can't tell 
you how many times I've had arguments with idiots who think it's OK to 
call a method "m".  Like, $myObject->m($something, $somethingElse).
I mean, what the f**k does that do?  And their chief justification? 
Because it's easy to type.  Well, uh, PISS OFF.

OK, I'll stop ranting.  :-)

That's my 2c for the P2EE standards.

Kyle Dawkins
Software Engineer
Central Park Software
http://www.centralparksoftware.com

Re: Augmenting CPAN with P2EE specs, was CPAN polution

[Gunther Birznieks <gu...@extropia.com>]

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://archive.develooper.com/perl-qa@perl.org/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