Re: new subcategory "Node" & something about processes

I agree with the extended sockets, however, it shouldn't be that hard to write a Net_Socket implementation that checked if the PHP sockets extension was compiled in, and enabled extra features if it is. I already do this in my Net_DNS module, because the Net_Socket class does not have some of the important features of a standard socket library (simply because it's not available in PHP without the socket extension). I previously considered developing this, but haven't really found the time. My idea is simple. First, reimplement all of the existing Net_Socket features with the php socket extension. Then extend the existing class to include features like select(). However, it's more important to select on a set of socket descriptors, not a single descriptor. Sockets in PHP include a socket_select(). There is no generic select call that can be applied to "file" descriptors, otherwise known as resources. So, you can't really make a generic IO::Select class like PERL has. You have to have a specific Socket_Select class. I suppose this could be abstracted by checking the type of resource that is passed in the FDSET, but you wouldn't be able to mix resources of different types if each requires a different underlying PHP select call... Either way... i'd be interested in helping with the development of the new Socket class using the PHP socket extension. Is someone leading this project? Has someone already devoted time to developing this. If not, I suppose I could get something started. eric On Sun, 24 Nov 2002, Stephan Seidt wrote: > Hm.. Sounds good. > One Socket_Base and several abstract classes with different constructors and members. > > On Sun, 24 Nov 2002 10:15:53 -0500 > sterling@bumblebury.com (Sterling Hughes) wrote: > > > > > Why not just have a top level namespace, "Socket", with subclasses like > > > > Socket_Unix > > Socket_tcp > > Socket_vector > > > > whatever.... > > > > If you are looking at SHM, Pipes, etc. Use the IPC sub-directory... > > > > -Sterling > > > > > > Hm.. Yes.. But why don't leave Net_Socket how it is and create some new > > > category then. > > > > > > No problem with this at all, except that I still think all this stuff is > > > vaguely networking related, and so belongs under the Net/ namespace in PEAR, > > > and the Networking category on the pear website. > > > > > > > Socket is much more than a tcp/udp network socket. And where to store fifo > > > or sysvmsg stuff then. > > > > As said in pear's documentation I know that something shouldn't be > > > > twice > > > available in pear. > > > > > > Well it shouldn't be available twice if the two are indifferent. If however > > > there is sufficient difference, then there's no problem having two > > > implementations. > > > > > > > But in this case the second Socket solution would provide lots of nice > > > feautres. > > > > Because of portability, the socket extension also works for windows. > > > > But I think you're talking about "Should i install php with sockets > > > > now > > > because of that?" > > > > Well.. If someone hardly needs unix sockets in the script he must install > > > the extension. > > > > Why shouldn't Pear provide a nice interface to use them ? > > > > > > I never said it shouldn't. > > > > > > -- > > > Richard Heyes > > > V-webmail - http://www.v-webmail.co.uk > > > > > > > > > -- > > > PEAR Development Mailing List (http://pear.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >