apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: AF_UNIX sockets in APR...
Date Wed, 31 Jul 2002 04:48:49 GMT
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> "Ryan Bloom" <rbb@covalent.net> 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


Mime
View raw message