apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: [PATCH] Some named pipe hacking...
Date Sun, 24 Jun 2001 01:57:59 GMT
> NT already _has_ NT namedpipes (and so does OS/2).  so,
> you are proposing to 'shackle' the NT named pipes to 'local only',
> because some unix developers can't be ... well ... uhh...
> okay, i'll be polite, but it's the same thing, 'might be confused'
> by something that isn't a unix API.

No, that is complete bullshit and I want all of the Windows developers to
know that this type of argumentation is juvenile and isn't appreciated.
The purpose of APR is to provide a portable runtime.  If a function only
exists on Windows or OS/2, then use the native library for those functions.
If there is a specific behavior that you want to replicate on all machines,
then define the feature set -- I don't give a rat's ass if it already exists
in Win32, if you can't define what the features are then we can't bloody
well make it multiplatform (on the platform that has already implemented
the feature set, we will use the native calls).  If the Windows name
happens to match an existing Unix name, the Unix name wins because that
is the most likely platform for developers and client implementations of APR.
So choose another name for the feature set if the features don't match
those under Unix.

> i think that anyone looking at such a codepath, trying
> to work out what's going on, is going to do a double-take
> and get even more confused than if the nt impl. of apr_namedpipes
> just went straight through to the NT one and the unix one
> used some external proxying service to emulate the remote bits.
> IF they WANTED the remote bits.

That would be opening a security hole, just as UNC are security holes.


View raw message