[PHP-DEV] Re: sockets extension...pecl it
Jason T. Greene [EMAIL PROTECTED] writes: The biggest thing I would like to have complete *by 4.3* is good solid docs on this extension (There is some already done). I am planning on working on this, and I have had one volunteer to help out. Where are the current docs? I'd like to have a look at those so I can start working on my abstraction library (bona-fide Socket class) and get a feel for how the extension's *supposed* to work (without having to resort to looking at the source). The best thing I can do is start using it and see what breaks. Thanks, B -- Brian Lalor [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : Where are the current docs? [...] php.net/sockets -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc - It's not a fug, it's a beature. - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: sockets extension...pecl it
Markus Fischer [EMAIL PROTECTED] writes: On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : Where are the current docs? [...] php.net/sockets By which you mean the source? I asked if there was documentation outside of the source files. -- Brian Lalor [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
On Thu, Sep 12, 2002 at 10:54:14AM -0700, Brian Lalor wrote: On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : Where are the current docs? [...] php.net/sockets By which you mean the source? I asked if there was documentation outside of the source files. Yes, the documentation is at http://www.php.net/sockets (which redirects to the manual entry). -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
On 12 Sep 2002, Brian Lalor wrote: Jon Parise [EMAIL PROTECTED] writes: By which you mean the source? I asked if there was documentation outside of the source files. Yes, the documentation is at http://www.php.net/sockets (which redirects to the manual entry). Thanks for bringing that up, Jon. How do I know which version of the documentation applies to a particular released version of PHP? We're still using php 4.0.6 where I work, but the documentation for the sockets library (for example) reflects some newer (unspecified) version and doesn't apply what I'm using. Is the documentation versioned in some way I'm missing? It's not versioned. Most of the time the documentation refers to the latest release (or even CVS version). Also if you are going to play with sockets you really shoul be using versions later than 4.0.6. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: sockets extension...pecl it
Jon Parise [EMAIL PROTECTED] writes: On Thu, Sep 12, 2002 at 10:54:14AM -0700, Brian Lalor wrote: On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : Where are the current docs? [...] php.net/sockets By which you mean the source? I asked if there was documentation outside of the source files. Yes, the documentation is at http://www.php.net/sockets (which redirects to the manual entry). Maybe I'm asking the wrong question. Where can I find the source for what's displayed on php.net[1]? [1] http://www.php.net/manual/en/function.socket-connect.php -- Brian Lalor [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
On Thu, Sep 12, 2002 at 01:13:03PM -0700, Brian Lalor wrote : Jon Parise [EMAIL PROTECTED] writes: On Thu, Sep 12, 2002 at 10:54:14AM -0700, Brian Lalor wrote: On Thu, Sep 12, 2002 at 10:41:47AM -0700, Brian Lalor wrote : Where are the current docs? [...] php.net/sockets By which you mean the source? I asked if there was documentation outside of the source files. Yes, the documentation is at http://www.php.net/sockets (which redirects to the manual entry). Maybe I'm asking the wrong question. Where can I find the source for what's displayed on php.net[1]? [1] http://www.php.net/manual/en/function.socket-connect.php In CVS like everything else :) Module phpdoc , en/reference/sockets/functions/* http://cvs.php.net/ (currently slow as always for me) -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc - It's not a fug, it's a beature. - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: sockets extension...pecl it
Jason Greene [EMAIL PROTECTED] writes: This extension does not belongs in PECL. It is fully platform compatible, all other languages offer this functionality, it is actively maintained (by me), and it will be marked stable by version 4.3 Jason, can you help me understand what needs to be done to make this extension non-experimental for the next release of PHP? Can we at least finalize the API so that *I* can work on a migration path for my own work? What help do you need? -- Brian Lalor [EMAIL PROTECTED] [EMAIL PROTECTED] (v) 480-333-3196 (f) 480-760-9298 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension...pecl it
What I was saying in my earlier email much longer drawn out email was, that the API changes have been really final since version 4.2.0. The only reason I would change it, would be if someone demonstrated a problem with the interface, which no one has for 4.2.0 - 4.2.3 versions. The only API changes that could possibly occur in the future would be the vector functions, and (of course) there could always be the addition of more functions. Most of the other work needed to mark the extension stable has been done, all that remains is that I have some small win32 work left to do. The biggest thing I would like to have complete *by 4.3* is good solid docs on this extension (There is some already done). I am planning on working on this, and I have had one volunteer to help out. If you are really interested in helping out, there are multiple options: * send examples * help out with docs * send patches * open bug reports * close bug reports : ) Thanks, -Jason On Wed, 2002-09-11 at 17:34, Brian Lalor wrote: Jason Greene [EMAIL PROTECTED] writes: This extension does not belongs in PECL. It is fully platform compatible, all other languages offer this functionality, it is actively maintained (by me), and it will be marked stable by version 4.3 Jason, can you help me understand what needs to be done to make this extension non-experimental for the next release of PHP? Can we at least finalize the API so that *I* can work on a migration path for my own work? What help do you need? -- Brian Lalor [EMAIL PROTECTED] [EMAIL PROTECTED] (v) 480-333-3196 (f) 480-760-9298 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: sockets extension
Wez Furlong [EMAIL PROTECTED] writes: Which part of EXPERIMENTAL in the docs at http://www.php.net/manual/en/function.socket-select.php don't you understand? If you're so desparate to have things cemented, write a patch, post it here and we'll commit it. If you don't have the skills, you might consider offering those that do some positive incentive to do it for you. The problem, Wez, is that this extension has been experimental for nigh on two years, now. The API has been completely changed three times and never in compatible ways. It is about time someone finished *one* cut of this thing! Finish it off, work out the bugs, and even if it is a nasty mirror of the C socket interface, at least there will be something supported. If you can't make up your mind, rework it for socket2, which can replace the then-deprecated socket extension. Every other scripting language has worked this out, so it can't be too difficult. Clean it up and push it out the door and let us have a working extension. At this point, I'm going to have to fork it for internal use because we need a reliable interface for communicating with our back-end systems. It should not have to be up to the user to dig through CVS log entries and php-dev postings to figure out when an age-old extension is going to be solidified. I apologize for the tone and frustration oozing out of these messages; I am responsible for building PHP for our development and production environments, as well as coding applictations that use the extension. I am unable to keep up. B -- Brian Lalor |http://introducingthelalors.org/ [EMAIL PROTECTED] (email) | [EMAIL PROTECTED] (jabber) N33°27.369' W111°56.304' (Earth) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: sockets extension
For the benefit of other users i did a status check on the general situation with extensions: Total extensions bundled with PHP4.2.3 = 94 # of them that are Expermintal = 24 Therefore more than 25% are expermental. Among the experimental. Experimental for 19 months to 2yrs --- sockets, openssl, crack, domxml, dotnet, iconv, ingres, java, ming, qtdom, rpc, satellite, skeleton, vpopmail Experminatal 10 to 16 months: --- dio, w32api, xml rpc, ncurses, pcntl, xslt Extensions not accessible via cvs.php.net !! --- mailparse, dbplus, muscat It might be nice to get rid of (or pecl it, as suggested by shane) the ones that show no (or false) promise of future stable versions to end users. And perhaps prioritize a little higher, some of those useful ones. -- Roshan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: sockets extension
For the benefit of other users i did a status check on the general situation with extensions: Total extensions bundled with PHP4.2.3 = 94 # of them that are Expermintal = 24 Therefore more than 25% are expermental. Among the experimental. Experimental for 19 months to 2yrs --- sockets, openssl, crack, domxml, dotnet, iconv, ingres, java, ming, qtdom, rpc, satellite, skeleton, vpopmail ok, so domxml is being worked on every day. the api is changing pretty frequently skeleton is the skeleton module, not really a module.. and others have been abandoned... Extensions not accessible via cvs.php.net !! --- mailparse, dbplus, muscat mailparse is in pecl, muscat died, i think. We are trying to move to pecl.. slowly... it's just a slight uphill struggle :) -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension
On 09/09/02, Brian Lalor [EMAIL PROTECTED] wrote: Wez Furlong [EMAIL PROTECTED] writes: Which part of EXPERIMENTAL in the docs at http://www.php.net/manual/en/function.socket-select.php don't you understand? I didn't mean for that to come across quite so strongly; I apologize. The problem, Wez, is that this extension has been experimental for nigh on two years, now. The API has been completely changed three times and never in compatible ways. That is unfortunate (but experimental does mean that things can change!). However, there has been a lot of work in this area recently (in HEAD), so I would hazard a guess to say that it is stabilizing (I think Jason has done a lot of good work here). Part of the problem here is that HEAD has such a large quantity of enchancements, new features and bug fixes (with a few things still pending some more polishing) that the last few official releases have been based on code that was branched a very long time ago. The user (perhaps quite rightly) expects that a new release will have everything they were hoping for, but is dissappointed when it doesn't, because the code that has those new features is locked up in the development version. While we try to backport fixes as we find them, our policy is to not backport new features (which might introduce new bugs); and since all the work on sockets is classed as new features, virtually none of it has made it into the 4.2.x series. It's a bit of a crappy situation, but we are not too far away from a 4.3 release that should make a lot of people happy. At this point, I'm going to have to fork it for internal use because we need a reliable interface for communicating with our back-end systems. Instead of forking it, get a CVS account and improve what we have in CVS for everyone - your help is welcome! [If you're doing this on company time and your boss/manager is a bit touchy about contributing just point out that your company can have it's name/url listed in the credits for PHP :-)] That's how I got into PHP; I wanted to use SSL for my sockets (fsockopen and fopen) in a commercial project, so I wrote a little patch. However, that simple patch grew into the idea behind the streams API; it's now something like 18 months and that code still hasn't made it into a release - is it because we are sat on our hands? No - we are all very busy people and getting something working well enough to pronounce it as stable takes a lot of time, effort and responsibility. The moment we mark an extension as stable we get stuck with the lumbering inertia of backwards compatibility. (and that would be far worse than the current situation!) I apologize for the tone and frustration oozing out of these messages; I am responsible for building PHP for our development and production environments, as well as coding applictations that use the extension. I am unable to keep up. Then take a front-seat role and start driving :-) Your frustration is understandable, but if you are about to do the work to make the extension work properly, you might as well share it - and then you can rely on it being in future releases. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension
Experminatal 10 to 16 months: --- dio, w32api, xml rpc, ncurses, pcntl, xslt dio - appears mostly stable = hell it's going in an embedded box here:) its a straight map direct unix io stuff to php, so the api will probably not change, just grow slightly?? Sounds like it could loose the experimental tag. pcntl - have tested the latest changes that jason did. - everything is ok here. - the api is stable, and unlikely to have major changes (again it's a pretty straight C-php api) anyway just my 2c Regards Alan Extensions not accessible via cvs.php.net !! --- mailparse, dbplus, muscat It might be nice to get rid of (or pecl it, as suggested by shane) the ones that show no (or false) promise of future stable versions to end users. And perhaps prioritize a little higher, some of those useful ones. -- Roshan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension
On Mon, 9 Sep 2002 16:59:19 -0700 NAIK,ROSHAN (HP-Cupertino,ex1) [EMAIL PROTECTED] wrote: Extensions not accessible via cvs.php.net !! --- mailparse, dbplus, muscat You missed a folder 'cvsroot/pear/PECL'. Experimental is a good state for extension where the interfaces are not stable (BC break), keeping them in the distribution is good to get more feedback, especially DOM_XML for example. imho, PECL is very good, but I m a bit afraid to see it move to a RD cvs if all experimental/non stable/whatever moves from php to pecl. Anyway, I m just a little pear developer, so :) pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sockets extension
First of all, If you have actually been having problems with this extension, all you need to do is open a bug report and/or email this list, and I would have been happy to take a look at fixing any possible issue. Now, to answer your question about why the api has undergone 3 changes: This is because the original version of the extension that was contributed was very platform specific, and the developer who wrote did not have too much time to maintain it. Afterwords, Sterling did a lot of the maintenance and enhancement work on it, but he is very busy working on other areas of php. Daniel Beulshausen then came in and wrote the win32 port, and changed the api quite a bit. He also started the task of it following php extension standards (i.e. namespacing the function names). After fixing a few bugs, I noticed that this extension needed a lot of work to make it rock solid. I then emailed the list with a plan to enhance and fix several aspects of this extension, as well as requesting feedback from all users of the extension. *i got _VERY_ few responses*. Although, those that I did get responses from did provide good feedback and suggestions. I announced in my mailing that all API changes would be finalized in version 4.2.X, and that if all issues were resolved by 4.3, then the extension would be no longer marked experimental. http://marc.theaimsgroup.com/?l=php-devm=101554464018314w=2 We are proceeding along quite as planned. I have committed myself as the extension's MAINTAINER, and I am still planning to mark it as stable by 4.3..The one exception is that I will most likely mark the vector functions experimental, as their are still some issues with them, and I am not sure about their current implementation. One area that I have been really hoping on focusing on before 4.3 is getting some good solid docs that reflect how to use this extension. (Sorry they haven't come sooner, I have just been so busy lately) I do greatly plan on keeping this extension production quality, as I use it in a 24x7 environment. If you are equally committed to having a solid sockets extension in php, then you are more then welcome to help out. Thanks, -Jason [EMAIL PROTECTED] -- Brian Lalor |http://introducingthelalors.org/ [EMAIL PROTECTED] (email) | [EMAIL PROTECTED] (jabber) N33°27.369' W111°56. 304' (Earth) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
vs.
while(($retval==socket_read($sock, $buf, $len)) 0) {
// do something
}
if ($retval==-1) {
print strerror(socket_last_error($sock));
} elseif ($retval==0) {
$eof=1;
print Eof has occured!!!;
}
what about
while(socket_read($sock, $buf, $len)) {
// do somthing
}
switch (socket_last_error($sock)) {
case SOCKET_EOF:
print eof;
break;
default:
print strerror(socket_last_message($sock));
}
harald.
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBPHeMRK1+myS9SSHxEQK7TgCcCP8Z4vdnVfFOhjhBX+y/WBQ196UAoKl1
BPYcQ7yUWFo/O0VeJwf/9lE6
=xYWI
-END PGP SIGNATURE-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
On Wed, 2002-02-20 at 19:29, Richard Samar wrote: Hi Jason, Hello Richard, I was the extension user talking about a few of the problems :-) I still had not the time to take a look at all the functions. 1. Consistency problems a. Some functions take host, some take ip, some take both b. Parts of the code use socklen_t, parts use int c. Windows code doesn't support PHP_NORMAL_READ d. Some protos are off with the function +1 to all of that and adding that: that stuff like arg1, arg2, arg3arg6 should get sensible variable names. %-) Agreed. 2. Logic Problems a. Max fd code does not work correctly (wrong approach) b. socket_recv does not properly handle error conditions 3. API problems [...] b. socket_create_listen only allows a listener to be installed on the local interface I think this is the idea behind this function which is actually a combination of creating binding and listening (if I recall correctly) for connection-oriented sockets. I would keep this, as this is just a quick and handy version for the probable most used server-socket. Right, and I am not suggesting getting rid of it. I was merely saying that if the function creates on the local interface only, it should be called socket_create_local_listen() instead. I think the concept of a quick socket bind listen is a great idea; however it should allow you to bind on any ip not just 127.0.0.1 (which should actually be INADDR_LOOPBACK) My suggestion is the following syntax change: socket_create_listen(port, [host/ip], [backlog]); c. socket_last_error clears the last error after reading (WTF) I think that this is meant to be so too. It does appear that this was meant to be this way; however, the only reason I can think of for that behavior, would be using socket_last_error() as an error check like if(socket_last_error) print error has occured. If that was the intended reason, I don't think it is very intuitive. actually there wouldn't be that many BC concerns through the named changes. An entire review would be good as some more little bugs might be found which prevented the use of the extension anyways. Well it would break anyone's code using socket_fd_*, socket_select, or socket_recv. However, I think that the users of those functions would have no problem adapting. I thought about changing socket_read to the same behavior that I am planning for socket_recv, but I think the purpose of socket_read is to be a very simple and easy to use function for reading sockets. If the time has come for the app to catch all conditions, then socket_recv() is the way to go. -jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
I'm all for fixing this extension up to make it better, but I'm a little concerned with totally dropping the fd_* functions. How would you mimic their use in something like a multiplexing using a blocking call situation after the change? I have no idea how it can be done without using the fd_* function. (But then again, I'm used to using the FD_* macros in C, so maybe there's better way in PHP.) Just wondering, because I acutally use this extension in a multiplexing kind of way with indefinite socket_select blocking and multiple clients and all that jazz already. Yeah, I know it's experimental and stuff, but it has yet to fail, even with my daemon script running for weeks on end under a fair load. I use the socket functions in a search engine that's constantly listening for connections using socket_select, and the socket_fd* functions are used quite a bit, hence my concern. (Not that I'm adverse to the change, 'cause I'm sure I'll cope, but I'd like to know if it will be possible to port my existing stuff over to the new API.) J Jason Greene wrote: 2. Get rid of socket_fd_*. - It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
On Thu, 2002-02-21 at 18:09, J Smith wrote: I'm all for fixing this extension up to make it better, Great!!! but I'm a little concerned with totally dropping the fd_* functions. How would you mimic their use in something like a multiplexing using a blocking call situation after the change? I have no idea how it can be done without using the fd_* function. (But then again, I'm used to using the FD_* macros in C, so maybe there's better way in PHP.) Well, since you know the C-API, lets look at if from the C socket API perspective. select() is designed to take 3 arrays. The problem with arrays is that they take up memory and processing time. In application space this really isn't a problem, but in the kernel, every saved byte counts. To optimize this they emulated arrays using bit masks. Another optimization they performed is to have you pass the highest file descriptor + 1 into select. (that way they only process part of the bit mask.) What I am getting at, is that FD_* was an interface designed strictly for kernel performance. Direct manipulation of these low level values does not really belong in a high-level language. The method that makes the most sense is to use php arrays in place of the fd masks. Everything would work exactly the same, except it would be much easier to interface, it would be less buggy, and require less code. By the way, the bug with the socket_fd_functions, is that it may set your maximum file descriptor incorrectly, and this would cause you to miss events occurring on ready sockets. (This occurs anytime you call socket_fd_clear() on a socket, or if you don't add sockets in order they were opened ex. 3, 1, 2 will cause you to lose file descriptor 3. example ?php // ... $read_flds=array($socket1, $socket2, $socket3, $socket4, $socket5); $write_flds=array($socket6, $socket7, $socket8); $except_flds=array($socket9); // Wait on sockets specified in arrays, and modify them to contain // sockets that are ready $retval = socket_select($read_flds, $write_flds, $except_flds, 1); //Perform actions on sockets waiting to be read foreach($read_flds as $read_sock) perform_read_action($read_sock); //Perform actions on sockets waiting to be written foreach($write_flds as $write_sock) perform_write_action($write_sock); //Perform actions on exceptions foreach($except_flds as $except_sock) process_exception($except_sock); // ... ? Just wondering, because I acutally use this extension in a multiplexing kind of way with indefinite socket_select blocking and multiple clients and all that jazz already. Yeah, I know it's experimental and stuff, but it has yet to fail, even with my daemon script running for weeks on end under a fair load. I use the socket functions in a search engine that's constantly listening for connections using socket_select, and the socket_fd* functions are used quite a bit, hence my concern. (Not that I'm adverse to the change, 'cause I'm sure I'll cope, but I'd like to know if it will be possible to port my existing stuff over to the new API.) I would like to see this extension become stable so that people can start relying on somewhat frozen behavior. To answer your question It should be pretty easy to port your code to the newer API. I appreciate hearing concerns like this, and I hope you and others continue to speak up. : ) -Jason J Jason Greene wrote: 2. Get rid of socket_fd_*. - It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
Hi Jason, I was the extension user talking about a few of the problems :-) I still had not the time to take a look at all the functions. 1. Consistency problems a. Some functions take host, some take ip, some take both b. Parts of the code use socklen_t, parts use int c. Windows code doesn't support PHP_NORMAL_READ d. Some protos are off with the function +1 to all of that and adding that: that stuff like arg1, arg2, arg3arg6 should get sensible variable names. %-) 2. Logic Problems a. Max fd code does not work correctly (wrong approach) b. socket_recv does not properly handle error conditions 3. API problems [...] b. socket_create_listen only allows a listener to be installed on the local interface I think this is the idea behind this function which is actually a combination of creating binding and listening (if I recall correctly) for connection-oriented sockets. I would keep this, as this is just a quick and handy version for the probable most used server-socket. c. socket_last_error clears the last error after reading (WTF) I think that this is meant to be so too. 2. Get rid of socket_fd_*. - yes. a very important thing. I didn't take a deep look at everything but it seemed to try matching the C functions 1:1. It makes little sense to make fd masks available to the user, because this can be much easier to handle by using arrays. I had the very same idea. This will fix the max_fd code that attempts to calculate the highest file descriptor in the fd_set. Select would then look like socket_select (array read_socks(), array write_socks(), array except_socks(), int tv_sec, int uv_sec) :-) 3. Add socket_clear_error(), and change socket_last_error() to not clear - I think that socket_last_error() clearing the last error is a huge WTF I am not sure about this. I don't think that it is a big problem. but...wtf ;-) I guess it is not such a big change. I would like to fix all of this by 4.2.X. I propose that we then mark the extension as stable, and freeze the API. actually there wouldn't be that many BC concerns through the named changes. An entire review would be good as some more little bugs might be found which prevented the use of the extension anyways. greetz -moh -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG
...posting at 2:30am can lead to interesting sentence constructions. my appologies :-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
