> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > > "Ryan Bloom" <[EMAIL PROTECTED]> wrote: > > > 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. > > I agree with your sentiment, and frankly, I don't care whether we use > apr_socket_t or not, as long as I can use the same functions to read and > write to AF_UNIX and AF_INET sockets, because that's what I really need to > do... :)
Okay, the read/write stuff is going to be hard to do, but maybe this is the reason to finally implement the IO Layers. Justin, as for the API, it should mirror the apr_socket_t API almost exactly. I say almost, because there are a lot of functions in apr_socket_t that aren't needed in AF_UNIX sockets. The only reason not to use apr_socket_t, is that the Windows implementation is 100% separate from the AF_INET implementation. While a separate type will suck on Unix, it will speed up Windows and make the implementation workable and readable on that platform. Ryan
