Re: [PHP-PEAR] Re: [PHP-CVS] cvs: php4 /pear/Experimental README/pear/Experimental/HTML Menu.php

[André Langhorst <[email protected]>]
> > DB
> > Benchmark
> [...]
> 
> > Shedule
> > XML_RPC
> > XML_Parser
> > XML_Render
> 
> this is not very forethoughtful (if you thought to put them into the
> top-level directory), these kind of structures are simply to flat to
> contain a large amount of classes
> 
> in a previous mail I already have asked on feedback for a top level
> differentiation between classes and applications, like this...
> 
> /classes
> /applications (maybe /apps)
> and other PEAR _internal_ dirs like
> /tests
> /scripts
> 
> and then I am in favor creating at least one layer of directories
> below to be able to group the packages to avoid ending up like CPAN
> 
> in the previous mail I have thought up just these
> /Math
> /Science
> /Template
> 
> but what we need is a bit more like this:
> http://www.hotscripts.com/PHP/Scripts_and_Programs/
> 
> there are many entries and some of them can be abridged to more
> generic directories for sure

The structure in question here is the directory structure of the
"pear" CVS module, and how packages should be named.  The structure of
the php4/pear directory mirrors the structure of the installed files.
With independent packages this correlation will be no more, the
"package.xml" file within each package determines which files end up
where in the install tree.

So I see two issues here: The first issue is whether the CVS module
structure should be flat on the top level (like I originally
suggested), or what kind of structure it should have if not.  

The second issue is whether the package names should have something
similar prepended to them.  My opinion is that whatever we do, it
should be immediately obvious to people what CVS module directory a
package has.

This split is necessary for PEAR to grow and getting some control on
the quality of the released code (or rather, giving this control to
the people who write the code).  Another result I am hoping for is a
stronger sense of ownership among current contributors, and that it
will be easier for new contributors to get up to speed (since they
only have to deal with a smaller project, not the whole monolithic
pile of code that PEAR is today).

It is very important that we have the same concept of what a package
is now.  We are basically following CPAN's model, plus the package.xml
file.

 - Stig

-- 
  Stig Sæther Bakken <[email protected]>
  Fast Search & Transfer ASA, Trondheim, Norway