Re: Re: cvs: php4 / TODO-4.1.txt

From: Date: Wed, 18 Apr 2001 22:53:02 +0000
Subject: Re: Re: cvs: php4 / TODO-4.1.txt
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-51899@lists.php.net to get a copy of this message
[Ron Chmara <ron@opus1.com>] > "Frank M. Kromann" wrote: > > > > Is there a list of modules that stays ? > > One of the things I've noticed on this topic is that a few > folks tend to think that their particular technology should > be used everywhere, and therefore, it should always be > installed on machines. Of course, this is how we got into > this convoluted situation in the first place... sure, > "XYZ functions" may be touted as a future standard for all > machines, someday, but quite frankly, many of such "standards" > aren't even close to widespread use and deployment. > > In response to Zeev's point that we don't even know if/how PEAR > will work, yes, I think this discussion isn't about enforcing the > future. I'd say it's more about finding some better direction. > > A proposed list where it "cuts close to the bone": > (since nobody seems to want to be the 'bad guy', I'll start...) > > M= Main > P= Pear > (To show/expose any personal bias, items marked with a "*" are ones that > I use on most servers.) > > apache M * > aspell P * > bcmath P * > bz2 P > calendar P > ccvs P > com P > cpdf P > crack P * > ctype P > curl P > cybercash P > cybermut P > db P > dba P I'd like to see dba stay. > dbase P > domxml P > dotnet P > exif P > fdf P > filepro P > fribidi P > ftp M * > gd P * > gettext P > gmp P > hyperwave P > icap P > iconv P The iconv library in itself is useful enough that we should try to keep this one within PHP, maybe even integrate it tighter. > iisfunc M > imap M * > informix P > ingres_ii P > interbase P > ircg P > java P > ldap M * > mcal P > mcrypt P * > mhash P * > midgard P > ming P > mnogosearch P > msql P > mssql M > muscat P > mysql M * > notes P > oci8 P * > odbc P > openssl P > oracle P > ovrimos P > pcre P PCRE should be in the main distribution, a lot of PEAR code relies on it. > pdf P > pfpro P > pgsql M * > posix P > printer P > pspell M * > qtdom P > readline P > recode P > sablot P > satellite P > session M > shmop M * > snmp P * > sockets M * > standard M * (duh. :-) ) > swf P > sybase P > sybase_ct P > sysvsem M * > sysvshm M * > vpopmail P > wddx P > xml P *BLAM* That's the sound of someone shooting himself in the foot. The PEAR installer needs the XML extension. :-) > yaz P > yp P > zlib P > zziplib P > > Which would mean that the main distro would have: > apache > ftp Why ftp, when for example curl is out? > iisfunc > imap > ldap > mssql > mysql > pgsql I'm willing to bet my best cap that oci8 is much more used than mssql. > pspell Why? > session > shmop > sockets > standard > sysvsem > sysvshm > > This keeps the core system functions, basic database > services for the most widely used DB's, and the basic > data exchange services (IMAP, ftp, ldap, etc.) > > Another way of looking at it would to leave almost everything > in some use, and only take out the ones which seem to be for > special purposes and work environments, such as an XML environment > pieces, or midgard, or hyperwave.... > ccvs P > com P > cpdf P > curl P > cybercash P > cybermut P > domxml P > dotnet P > exif P > fdf P > fribidi P > gettext P > hyperwave P > icap P > iconv P > ircg P > mcal P > midgard P > notes P > openssl P > pcre P > pdf P > pfpro P > qtdom P > readline P > recode P > sablot P > vpopmail P > wddx P > xml P > yaz P > yp P > zziplib P > > And, adding to the pear discussion, working with blocks of these > would undoubtedly be easier. So if you wanted to get the XML > package, it would grab xml, domxml, etc... Well, if you use domxml, you probably wouldn't use xml, because they offer two different abstractions/approaches to solve more or less the same problem. But such blocks (or bundles, like CPAN calls them) are a good idea. It'd be interesting to hear what extension maintainers think. - Stig -- Stig Sæther Bakken <ssb@fast.no> Fast Search & Transfer ASA, Trondheim, Norway

« previous php.dev (#51899) next »