> > While the code is small, to the best of my knowledge, it is also not > > portable. If it is portable, +1. If it is Unix only, -1. > > Well, it is not a "globally portable" feature... As fork(), for instance, > which doesn't exist on Windows, but still APR supports it.
Okay, I can accept that, except the while AF_UNIX isn't portable, the concept can be written portably. Aaron, Will, and I had this conversation a couple of months ago, and you can write domain socket-like logic for Windows. I do consider AF_UNIX different from fork(), because fork() is required for any complex programs on Unix, and Windows just can't support it. However, AF_UNIX can be written for Windows, albeit, it is a hack, and requires a combination of sockets and named pipes. > If APR provided me AF_UNIX, I would just use that... Please, don't make > the > same stupid mistake that Java did. I'm bashing my head on the wall > everytime > I see the java.net classes because they are not extensible, and because > every time that someone wants to use AF_UNIX, they have to write it on > their > own... Ok, it doesn't work on Windows, but it works on another 2 > bazillions > of UNIX implementations... I have no problem implementing this feature, but do it right (which may mean not using apr_socket_t), so that it is portable. We have enough people who have asked for this feature, that not implementing it is kind of stupid, but please, please, please, don't write the API such that it absolutely can't work on Windows. That completely removes the goal of APR. We have tried hard not to create functions that can't be written on one of our platforms. Please don't add a type of communication that isn't portable, that isn't useful in a portable library. Ryan
