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, arg3....arg6" 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
