> > 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.
While I agree with 99% of what Roy said, I would like to make one clarification from my point of view. I don't really care if it conflicts with a name on Unix. I do however care if the name conflicts with something in POSIX or something in common use on multiple platforms. If we implement something that conflicts with a name on Windows, and our implementation doesn't look incredibly similar to that entity on Windows, then I consider that a problem. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
