> > > Here is enough to look at to make sure I didn't screw anything up. I > > > added family and type parameters too so that APR doesn't have to bend > > > over backwards (i.e., use syscalls) to find that out. We don't keep > > > the type anywhere yet but it is likely to become useful in the future. > > > > I would really prefer that this function at least look like the current > > apr_put_os_* functions. That would mean just wrapping all of this > > information up into a single structure that is just passed to APR's create > > function. > > What is the purpose of putting the parameters into a structure? Do we > expect that we'll want to tailor the information provided to > apr_make_os_socket() on certain platforms?
Won't it need to be different on different platforms? I mean, Windows wants a SOCKET, and I wouldn't put it past M$ to change the sockaddr to some windows specific structure in the future. > I guess I'm not sure what you mean by "APR's create function..." Do > you want to change apr_create_socket() to take parameters in a > structure, and have the structure indicate whether or not we already > have the OS socket (I don't think this is what you mean). I meant apr_make_os_socket when I said the create function. > Should it be apr_make_socket() instead of apr_make_os_socket()? No. This is a portability function, and it should retain the os in the name. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
