On Wed, Jun 20, 2001 at 10:50:03AM -0500, William A. Rowe, Jr. wrote: > 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 uhh... okay.
okay, it's important to me, given what i would like to achieve. i explain below. sorry for not having mentioned it earlier. > > 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 wasn't, but i didn't say that, so you weren't to know, so i stand corrected for not communicating enough. > 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.) what i have been hinting at, and planning, is that i will actually provide, with the TNG architecture, is the FULL \\servername\\PIPE\pipename functionality. yes, that's right: i will write code that redirects to TNG, which will farm out the data over SMB over to a remote system FOR you. that's right: a unix apr application will be able to connect to a *remote* NT apr server. that's *remote* platform independence, not just local platform independence. and if you don't expose the full pipe-name in the APR api, i can't do that. > And return an opaque structure that the > platform may us to open handles on that pipe using an apr_filepipe_open() > call. ack to that. > > 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? see above. does that help? luke