From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2001 8:55 AM
> > You miss my point. We at _least_ need to return a "Windows Acceptable Pipe > > Name", instead > > of some /PIPE/pluming style name. > > it is *important* that NT-style conventions are followed. ... internally > the 'guiding light' *must* be the NT functions. No, the 'internal light' must be the platform-appropriate function. > i know that most of you may find this difficult to accept that > microsoft may be able to develop an API that's really useful, > and may feel 'tempted' to 'do better' by imposing 'unixy > style' conventions. > > please don't. We aren't. And you sir, are presuming that NT is the only 'obscure' platform out there. It isn't. I'm suggesting that we pass a pipe name to create/locate a pipe. No hokey pathing, simply a pipe name that will be normalized \\.\PIPE\name or /dev/pipe/apr/name (or however it ought to be named on win32.) And return an opaque structure that the platform may us to open handles on that pipe using an apr_filepipe_open() call. > you may be used to doing this the other way round: making NT do > what unix does. We aren't, we all agree that lcd coding is required on apr, and we offer extensions where they are needed. Heck, why could even accept unix "/dev/pipe/name" as a pipe, but it would be morphed into "\\.\PIPE\dev_pipe_name" in order to serve the data. > and if that means creating files like /tmp/.apr-socket/\PIPE\samr with > backslashes in them and i _know_ this _is_ possible to do on unix, > and i _know_ that there are no problems with doing so because winbindd > does it [i have a directory /home/DOMAIN\administrator on my linux > hard disk and even an entry in /etc/passwd to match it] then so be it. Why not simply a pipe name, and leave pathing to apr? Justification? Bill
