On Sat, Jun 23, 2001 at 06:57:59PM -0700, Roy T. Fielding wrote: > > 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.
uhhm... well, uhmm, sorry, i wasn't to know that's how it would be interpreted: it didn't look like it to me, otherwise i would have said something else, neh. hm, maybe... yeah, i was using reducto-ad-absurdum and then connecting that to implicit criticism of unix developers who may consider unix to be 'better' because it's not nt. nt does have some extremely well-designed apis, that are then rushed to market and botched in places. a great pity. _and_ they have a monopoly, which tends to wind _everyone_ up. > 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. hm. i'll have to think and get back to you. it is v. unfortunate that there is a named pipe on both NT _and_ unix, and they do different things. because here, the unix equivalent isn't _capable_ of doing anything _like_ as much as the NT equivalent. my point of the [reducto-ad-juvenile-conclusion] comments above were to say, well, if you have the same names, but different functionality, why would you want to limit the [apr] functionality to that of the least-functional api? so yes, changing the name for the apr equiv seems like an extremely sensible thing to do, here. it's caused enough hassle here already just discussing it! [and btw the points about lowest common denominator _do_ make sense to me, and i _do_ respect them]. how have such name/functionality conflicts been resolved in the past? the feature-set i need is very simple: - transaction and security-context passing between platform-independent, location-independent clients and servers. that means, in NT and OS/2 API terminology, the full functionality behind: CreateNamedPipe TransactNamedPipe in unix terminology, there _is_ no equivalent (unix is somewhat backward in this respect, being about 10 to 15 *years* - not man-years, _actual_ years, behind NT, and i'm not kidding here.) ...tell you what, i will write up an API proposal and morph some code to an apr api. less talk, more code :) > > 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. and that is the choice of the user of the application, and we know that. i am not sure what your background is, or that of the other people on the list. i worked for ISS for 18 months, and had security principles drilled into me. one of them was that security is a trade-off between functionality and risk. the best network security is an air-gap [unplug it!! :)] however, in practice, this is regarded as impractical and only a partial joke in the security community (paranoia rules), and so everything you do from that point onwards is a calculated risk. not many people actually bother to assess those risks, or are even aware of them, and it seems that you do, and are. so, that having been said, i am fully aware too of the risks of providing remote services - i've been developing them for five years. so, your point is noted, and my question is, is it enough to stop apr from doing it [NT-style namedpipes]? best regards, luke
