RE: [PHP-DEV] PHP 4.3 and PHP 5
| From: | Joseph Tate | Date: | Wed, 21 Aug 2002 14:55:55 +0000 |
| Subject: | RE: [PHP-DEV] PHP 4.3 and PHP 5 | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-87231@lists.php.net to get a copy of this message | ||
And a couple more things.
> Adding to the ever expanding list...
>
> On Wed, 21 Aug 2002, Sterling Hughes wrote:
>
> > > Hi all,
> > >
> > > Following on from the recent debug_backtrace discussion, and the
> > > discussion about just what we are releasing next and so on, I'd just
> > > thought I would make a couple of comments about PHP 4.3 and about what
> > > I think (IMHO) should be the goals of PHP 5.
> > >
> > > I'm currently reviewing the streams code, to make sure that the API is
> > > good enough for a release: there are a couple of things that I want to
> > > tidy up ready for PHP 4.3:
> > >
> > > o Add a "set-blocking-flag" method to the generic stream operations,
> > > So that non-blocking IO can be enabled on any stream that it makes
> > > sense to do so. (IIRC, there is a bug in the DB, or this deficiency
> > > was mentioned on the list).
> > >
> > > o Tidy up persistent streams support. (I need some help from someone
> > > that
> > > really knows what they are doing here). This is important, because
> > > I'm not sure that persistent sockets (pfsockopen) are
> actually working
> > > in HEAD ATM.
> > >
> > > o Implement a filter API, so that filters can be stacked over
> a stream.
> > > I've mentioned this before; it will be useful to stack things like
> > > base64, charset conversion, zlib/bzip compression and crypto over a
> > > stream - potentially multiple filters. I don't think that this will
> > > take too long to implement (perhaps by the weekend).
> > >
> > > o Implement stat() and readdir() for ftp. I think http will be "too
> > > hard"
> > > to achieve in time for 4.3.
> > >
> > > PHP 5
> > > -----
> > >
> > > Zeev raised the issue of figuring out what we want to be in PHP 5.
> > > Well, I can't think of (m)any fancy new features for PHP 5 that we
> > > haven't already got in HEAD, but to get the ball rolling, this is my
> > > take on how PHP 5 could/should look:
> > >
> > > Current HEAD, stabilized. This includes things like the new build
> > > system, streams, enhancements to post/file uploading, domxml
> and so on.
> > > ZE2, feature complete. (New OO, better rpc/com/java, try/catch,
> > > delegation, etc. etc.)
> > >
> > > To me, that sounds really pretty good. Yes, it's just HEAD with ZE2,
> > > but I think it's almost what will be PHP 5. A couple of
> additions that
> > > would make it more attractive:
> > >
> > > o PEAR/PECL CA fully established. I know that we are aiming to get
> > > this off the ground for PHP 4.3, but I'm sure we can improve
> it for PHP
> > > 5.
> > >
> > > o Bundle Brads php-soap extension, and "market" PHP 5 as being "Web
> > > Service Enabled".
> > >
> >
> >
> > o Finish off Harald's RPC extension, which should provide "Seemless" web
> > services. Move Brad's extension into PEAR/PECL, for those
> people who need
> > to use soap in a manly, yet sexy way.
> >
> > o We really need some people to look at PHP's XML support.
> Yeah, currently,
> > it kinda-sorta works, however, we can really do it better. I
> suggest using
> > the DOMXML extension as a base (so much work has been done
> already). Test
> > strongly, Add full LibXML support, standardize the API to DOM's api, and
> > bundle libxml & libxslt with PHP version 5 (removing expat bundling).
> >
> > o See if we can get cURL bundled for PHPv5.
> >
> > o In that vein, get a proper standardized bundling scheme
> setup, that makes
> > it easy to bundle/unbundle software with PHP.
>
> o Update ODBC to v 3.7 support. The current v2 support just doesn't cut
> it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various
> large data field types, and unicode. I started this, but my resource
> books were ummm... acquired by another and never returned.
>
> o Decide if we are or are not going to support the iPlanet system. If we
> are, it needs to be drastically fixed, if we're not we need to drop it.
> Really. Look at the bug reports.
o Rewrite the ISAPI IIS interface. "Gasp". From the ground up, or find
some other way to fix bug #15333. The work arounds listed in the bug report
are not acceptable in production systems, just as temporary stop-gap methods
for developing new applications until a true fix is found.
o Fix register_shutdown_function to work as it did with 4.1, or add a
seperate function to add this functionality. And then get it to work on
windows. See bug #15209.