> On Thu, 2003-06-19 at 02:27, Wez Furlong wrote: > > I don't like it being enabled by default either, since it is experimental, > > unstable and broken. > > > > (and streams provides stream_socket_server() and stream_socket_client() as > > replacements for the most common uses of ext/sockets).
> Well, I dare say its less experimental than streams. Sockets has been > in production use for quite awhile now, the EXPERIMENTAL is just lying > around there. Well, lets put it another way: sockets is unmaintained (the author deliberately ignores PHP related mail and couldn't give a s**t about it) and broken (check the open bug reports and Rasmus has a few comments on the code quality), whereas streams is supported and not known to be broken :) > streams provides a reasonable abstraction, but it doesn't provide the > low-level access that is a pretty common requirement. Sockets provides > this without requiring anything extra, so why not use it? Sure, but you could say the same of many of the other extensions, so why don't we enable them all by default? :) My goal is to provide an API for each these common socket operations to streams. At the moment, we support socket server, socket clients, asynchronous connections, non-blocking sockets, select(), retrieval of the peer "name" and possibly some others. What other operations do most people need from sockets that is not listed there? (I know that I've rarely needed anything more than that in the last 6 years of hacking). Anyone that needs more than that can --enable-sockets when they configure :) --Wez. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php