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

Reply via email to