Re: new subcategory "Node" & something about processes

Don't you think it would be better picked up in a seperate category? I agree with you that the new socket would just show an extended version of the current Net_Socket, but I mean it wouldn't be nice to mix the new Socket with the old one together. If someone requires simple sockets without compat for selects, serversockets, etc this person should choose the basic Net_Socket. It wouldn't be nice for the developers to mix them together.. Every feature of php's socket extension would have to be checked for availability first. Every method of the class would need a control structure to do that and I think that doesn't look nice. What about our idea with the abstract sockets ? I think we should put the new Socket into this class as Socket_Socket. Several new Sockets for tcp, udp and local unix domain communication could be better stored there. The unix sockets would also fit into the new Socket category. Sterling Hughes already mentioned something like this : Socket_Socket Would be the base socket class. Socket_TCP An extended version with it's own constructor. It also uses it's parents receive function but passed the global constant SOCK_STREAM to it. Socket_UDP Also, but specialized for datagram receiving. Socket_UNIX This would need a method and a possibility int the constructor to let the user define if he needs stream or datagram. Socket_Select I think a static function would be nice here. It should be able to detect if an array of sockets, just a single one or something else was given. Socket_List Would be nice to be used for applications which have lots of sockets and require something for sending to all sockets, selecting or closing. If we could create all this stuff we would have a powerfull new category with a nice amount of usefull functions for using sockets. And because of the Net_Socket stuff. It's constructor could return a reference to a new instance of one of the new Sockets. bye On Sun, 24 Nov 2002 19:58:38 -0500 (EST) eric@ypass.net (Eric) wrote: > > 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: R�� > > > > .���L�|K��http://www.php.net/unsub.php > > > > > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >