Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt From: Stig Sæther Bakken (ssb <email protected>)
Date: 04/18/01

[Ron Chmara <ron <email protected>>]
> "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 <email protected>>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>