Guys,
Over the years, there's always been a tendency to think about things which
are 10 steps ahead. It never worked, and I don't think it would work here
either. Moreover, I don't see any advantage in discussing this now - on
the contrary - we really have no idea what we're talking about. Whether or
not we separate modules *at all* will greatly depend on how good an
implementation we end up having. How many of them we end up separating
will also depend on that. Let's just wait with those discussions until
they're somehow connected with reality.
Zeev
At 00:52 19/4/2001, Ron Chmara wrote:
>"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
>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
>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
>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
>yaz P
>yp P
>zlib P
>zziplib P
>
>Which would mean that the main distro would have:
>apache
>ftp
>iisfunc
>imap
>ldap
>mssql
>mysql
>pgsql
>pspell
>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...
>
>-Ronabop
>
>--2D426F70|759328624|00101101010000100110111101110000
>Personal: [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
>Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
>The opinions expressed in this email are not necessarily those of myself,
>my employers, or any of the other little voices in my head.
--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
