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:15:12 GMT
> > 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



Mime
View raw message