You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2002/07/31 02:50:40 UTC
AF_UNIX sockets in APR...
While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
of you, and I didn't hear any negative opinion from anyone...
This would be so great for me, as it would ease my work with Java, in having
a generic IO layer a little bit better than the current Java.IO and with an
extensive support for all kinds of sockets...
Are there strong feelings against it? Thanks...
Pier
Re: AF_UNIX sockets in APR...
Posted by Harrie Hazewinkel <ha...@lisanza.net>.
--On Tuesday, July 30, 2002 5:50 PM -0700 Pier Fumagalli
<pi...@betaversion.org> wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in
> having a generic IO layer a little bit better than the current Java.IO
> and with an extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
All I would add is yes. +1 for adding this. I already asked/mentioned
this to some APR developers over a year ago. :-))
Harrie
Internet Management Consulting
mailto: harrie@lisanza.net http://www.lisanza.net/
--------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
Re: AF_UNIX sockets in APR...
Posted by David Reid <dr...@jetnet.co.uk>.
I'm -0 on adding them as they're really NOT portable. All the code I've seen
to add similar functionality on non-unix platforms has been flawed in a
number of ways and doesn't actuallt equal a 1 - to - 1 replacement for
AF_LOCAL.
One thing is for sure, they can't be added to apr_socket_t as that would
destroy our abstractions (in that apr_socket_t wouldn't then be usable
across all platforms in the same manner).
Anyway, knock yourselves out.
david
----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "APR Development List" <de...@apr.apache.org>
Sent: Wednesday, July 31, 2002 1:50 AM
Subject: AF_UNIX sockets in APR...
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in
having
> a generic IO layer a little bit better than the current Java.IO and with
an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
>
> Pier
>
>
Re: AF_UNIX sockets in APR...
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in having
> a generic IO layer a little bit better than the current Java.IO and with an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
+1 from me too, and I'd like to see this integrated with the apr_socket_t
stuff so that we parallel the bsd sockets as much as possible.
-aaron
Re: AF_UNIX sockets in APR...
Posted by Harrie Hazewinkel <ha...@mod-snmp.com>.
--On Wednesday, July 31, 2002 10:18 AM +0100 David Reid
<dr...@jetnet.co.uk> wrote:
> What's next? Given that we seem to be adding this because "it's easy on
> unix" do we now have to start adding all the windows features we like? Oh
> no, we're mainly unix folks aren't we? Sorry, but comments like this make
> me verge more on the -1 than -0...
Hmm, maybe some features of windows are worth adding. Not that I can
think of it. I don't even have a windows system.
>
> APR does not exist to scratch everyones individual itch. Sorry Pier.
Hmm, I have seen over the past that I also had some 'individual
itch' as you express it. Some of them were after a long time even
added since the more core Apache folks needed them or they simply
did not like to original idea which later changed.
Harrie
Internet Management Consulting
mailto:harrie@mod-snmp.com http ://www.mod-snmp.com/
-------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management to the Apache server.
Re: AF_UNIX sockets in APR...
Posted by David Reid <dr...@jetnet.co.uk>.
Yeah, but this is really the thin end of the wedge... :(
What's next? Given that we seem to be adding this because "it's easy on
unix" do we now have to start adding all the windows features we like? Oh
no, we're mainly unix folks aren't we? Sorry, but comments like this make me
verge more on the -1 than -0...
We've talked about this before and we've said that what we're lacking is a
IPC api, not that we're lacking AF_LOCAL support.
APR does not exist to scratch everyones individual itch. Sorry Pier.
david
> On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom 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 think the biggest problem is that we (at least myself) don't know
> what type of API would work for Win32. If someone with knowledge of
> how this might work on Win32 could describe an API, I think we can
> come up with an implementation in Unix. Whenever someone cares
> enough to implement the bits in Win32, they can add it.
>
> And, +1 to the "not implementing it is kind of stupid" as we've had
> this debate way too many times for my liking. -- justin
>
Re: AF_UNIX sockets in APR...
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
> On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom 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 think the biggest problem is that we (at least myself) don't know
> what type of API would work for Win32. If someone with knowledge of
> how this might work on Win32 could describe an API, I think we can
> come up with an implementation in Unix. Whenever someone cares
> enough to implement the bits in Win32, they can add it.
>
> And, +1 to the "not implementing it is kind of stupid" as we've had
> this debate way too many times for my liking. -- justin
If any of you guys are at Defcon, I'd be happy to discuss this.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Available for contract work.
Re: AF_UNIX sockets in APR...
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jul 30, 2002 at 09:15:12PM -0700, Ryan Bloom 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 think the biggest problem is that we (at least myself) don't know
what type of API would work for Win32. If someone with knowledge of
how this might work on Win32 could describe an API, I think we can
come up with an implementation in Unix. Whenever someone cares
enough to implement the bits in Win32, they can add it.
And, +1 to the "not implementing it is kind of stupid" as we've had
this debate way too many times for my liking. -- justin
Re: AF_UNIX sockets in APR...
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 30, 2002 at 09:34:39PM -0700, Pier Fumagalli wrote:
> 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... :)
I don't see how we can do that unless you use apr_send/apr_sendv, which
both take apr_socket_t.
Since there are implementations of the bsd-style sockets on Windows
that support AF_UNIX/AF_LOCAL, I don't see why we don't just merge
that into our current apr_socket.h implementation.
-aaron
RE: AF_UNIX sockets in APR...
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> "Ryan Bloom" <rb...@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
Re: AF_UNIX sockets in APR...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Ryan Bloom" <rb...@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... :)
Pier
RE: AF_UNIX sockets in APR...
Posted by Ryan Bloom <rb...@covalent.net>.
> > 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
Re: AF_UNIX sockets in APR...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"rbb@apache.org" <rb...@apache.org> wrote:
> On Tue, 30 Jul 2002, Justin Erenkrantz wrote:
>
>> On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
>>> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
>>> of you, and I didn't hear any negative opinion from anyone...
>>>
>>> This would be so great for me, as it would ease my work with Java, in having
>>> a generic IO layer a little bit better than the current Java.IO and with an
>>> extensive support for all kinds of sockets...
>>>
>>> Are there strong feelings against it? Thanks...
>>
>> As one of the people you talked to at OSCON, here's my +1 for adding
>> it. I've even submitted patches before to do this - the additional
>> code is quite small. -- justin
>
> 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.
If AF_UNIX returned some APR_ENOIMPL under Windows, well, I'd be fine with
it. The PITA about not having it is that I have (and I've done that already)
to implement everything on my own, if I want to use AF_UNIX in those places
where I need it. I believe that having the advantage to use a specific
feature such as AF_UNIX (which is common to all platforms but Windows AFAIK,
dunno about OS/390, but...) in a portable way together with AF_INET sockets
IMO is FAR GREATER than checking for an APR_ENOIMPL return value when
someone under stupid Windows tries to create a socket with a path.
Look at my example here:
http://dev.betaversion.org/svn/jerry/head/jerry/java/org/betaversion/jerry/s
ocket/
I have a set of native acceptors (AF_???? server sockets), and right now,
for the stupid implementation, I cannot rely on APR, because it does not
support AF_UNIX...
http://dev.betaversion.org/svn/jerry/head/jerry/native/
So, I have to reimplement for "simplicity" also AF_INET, because in that
case, I have one "interface" (the stupid file descriptor), that works for
both of them, and I don't have to write my own little API different from
FDs, different from APR, different from everything to use FDs on AF_UNIX,
and APR on AF_INET...
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...
Pretty please with sugar on top...
Pier (how many times can you count "stupid" in this email?)
Re: AF_UNIX sockets in APR...
Posted by rb...@apache.org.
On Tue, 30 Jul 2002, Justin Erenkrantz wrote:
> On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> > While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> > of you, and I didn't hear any negative opinion from anyone...
> >
> > This would be so great for me, as it would ease my work with Java, in having
> > a generic IO layer a little bit better than the current Java.IO and with an
> > extensive support for all kinds of sockets...
> >
> > Are there strong feelings against it? Thanks...
>
> As one of the people you talked to at OSCON, here's my +1 for adding
> it. I've even submitted patches before to do this - the additional
> code is quite small. -- justin
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: AF_UNIX sockets in APR...
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jul 30, 2002 at 05:50:40PM -0700, Pier Fumagalli wrote:
> While at OSCON, I chatted about having AF_UNIX support in APR with a bunch
> of you, and I didn't hear any negative opinion from anyone...
>
> This would be so great for me, as it would ease my work with Java, in having
> a generic IO layer a little bit better than the current Java.IO and with an
> extensive support for all kinds of sockets...
>
> Are there strong feelings against it? Thanks...
As one of the people you talked to at OSCON, here's my +1 for adding
it. I've even submitted patches before to do this - the additional
code is quite small. -- justin