CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Mon, Jan 07, 2002 at 03:16:05PM -0800, Andrew Tridgell wrote:
> Luke,
> 
> I would have thought you'd eventually get sick of raking over these
> old coals. I know that I'm sick of explaining it to you for the
> hundredth time.
> 
> Here goes for the 101st ...
> 
> >  i've already described such a viable method.  unfortunately
> >  the people you work with are too arrogant and too stupid to
> >  accept anything that comes from me, and too short-sighted
> >  and cock-sure of their own technical superiority
> >  to accept any solution that is not "perfect".
> 
> no, you offered a solution, I pointed out flaws in it and proposed an
> alternative. That's the way software works. Yelling and swearing
> doesn't help.
> 
> >  loadable module support is _not_ the way to do it.
> 
> For those who have only just joined us the loadable module proposal
> goes like this:
> 
> - allow smbd to load arbitrary .so module for any pipe

 likely to be insufficient.
 
 see message i sent in response to jfm's message
 describing the lm proposal, three months ago.


> - a single .so can handle multiple pipes 
> - the .so can have its own parameters in smb.conf

> That's the basic infrastructure. Then to allow compatibility with
> existing TNG pipes I suggested we have a single simple "glue" module
> that is loaded into smbd and interfaces to the existing TNG pipes
> interface. So you might have something like:
> 
> pipe handler = *:pipe_tng_glue.so
> 
> (meaning "for pipes that match the name * use pipe_tng_glue.so")
> 
> or we could use symlinks in a pipe directory or whatever.
> 
> >  "controlled" from HEAD is not the way to do it.
> 
> well, if head is running then the packets will be going via smbd
> code. No choice about that.
 
  that's not the issue.

  how can an ARBITRARY dce/rpc-based program - NOT a .so - one
  that is UTTERLY INDEPENDENT of samba, run and register
  itself?

  if your pipe glue deals with this issue, then i will be
  amazed and will have finally got through to you, after just
  over two years of very unnecessary and painful experiences.


> >  no sane dce/rpc programmer wants their namespace polluted
> >  by samba function namespace [there are technical ways to
> >  deal with this, if you can be bothered].
> 
> see the glue pipe.
> 
> >  no sane dce/rpc programmer wants to have to waste their time
> >  looking through 350,000 lines of code [there are no technical
> >  ways to deal with this].
> 
> see the glue pipe again ...
> 
> >  dce/rpc server-programming the programmer expects to have
> >  total control over their application, and just use an API:
> 
> again, see the glue pipe ...
> 
> >  that way you can have a test server program of 400 lines of code,
> >  it's understandable, readable, simple, and totally independent.
> 
> right, see the glue pipe.

good.  finally.


> >  the last thing a dce/rpc programmer should have to worry about 
> >  is some stupid configuration file, and how to load it, of some
> >  totally separate package that has nothing to do with their
> >  application.  [read "smb.conf" for "stupid configuration file"].
> 
> as I've mentioned, the packets go via smbd if they are using the SMB
> transport, so you really can't avoid a smb.conf.
> 
> I don't imagine any of this
> (which has been said so many times before)

not to me it hasn't.

remember: you have not communicated to me any forward-thinking
or strategic software designs that will allow samba to rapidly
catch up with man-decades of microsoft proprietary practices,
except for the "glue" pipe idea.

> will stop you foaming at the mouth, 

wrong.  read my other message, in reply to jfm.

you're still so upset over the awful things that happened
at linuxcare that you still don't read my emails properly,
and so you still never see the way out, or take my advice.

hopefully, some time in the next decade, one of two things
will happen.  microsoft will collapse, resulting in NT
source code becoming public domain.  or you'll finally
be forced to make some technical concessions that
alleviate some of the burden of developing samba on your
own, in your own way, that you have forced upon yourself.

normal people like yourself can't keep a _well-informed_
map and a working knowledge / understanding of 350,000
[and going up] lines of code in their heads.

only autistic people [like myself] and people with photographic
memories _and_ a lot of time on their hands have any realistic
chance of taking on anything more than about 200,000 lines
by themselves.

for everyone else, it's _necessary_ to make their jobs
easier.  and since you are the one now in total control
of samba, just like you wanted, _you_ are the one that's
going to have to implement any such moves to a future-proof
design.

lkcl