CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Mon, Jan 07, 2002 at 03:16:05PM -0800, Andrew Tridgell wrote:
> Luke,

> I know that I'm sick of explaining it to you for the
> hundredth time.
 
 well, maybe you haven't addressed the issues that really
 concern me the most.

 everything else i really couldn't care less about.

 [that's a classic autistic asperger's syndrome trait, btw,
 that's caused me an awful lot of pain and trouble, but has
 also got me a long, long way.  swings and roundabouts].

> >  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 

your flaws i consider to be acceptable.  the functionality
was not affected, and the solution provided a trade-off
with strategic benefits that far exceeded the technical
"flaws".

flaws which, i might add, were, afaicr, a 10ms overhead
instead of a microsoft / samba 2.0 overhead of 1ms.

flaws which, i might add, are inherent in samba's design,
which i inherited over into the tng architecture as a
matter of first implementation cutting-and-pasting.

> and proposed an
> alternative. 

which, at the time, was not an acceptable alternative
on the grounds that it was a step backwards compared
to the tng architecture, not a step forwards, and
on these grounds i saw no reason to accept your
proposed alternative.

> >  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
> - a single .so can handle multiple pipes 

a single dce/rpc application may also handle multiple
"pipes", by registering more than one endpoint with
rpc_ep_register() before calling the rpc_server_listen()
function.

[a single dce/rpc application may also handle a hell of a
lot more than just "pipes", but for the purposes of this
discussion we'll keep to the common subset of functionality.]

lkcl