CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Tue, Jan 08, 2002 at 07:59:56AM +1100, Andrew Bartlett wrote:
> Elrond wrote:
> > 
> > On Mon, Jan 07, 2002 at 08:30:29PM +0100, Jelmer Vernooij wrote:
> > [...]
> > > Yes, I do support TNG, and I do think you are right with the different
> > > structure of TNG, but I doubt the current approach is right. Wouldn't
> > > patching the 'normal' be better?
> > [...]
> > 
> > The patch would be extremely large.
> > 
> > And so it would not be possible to handle it reasonable.
> > 
> > It's not only the rpc part. Many other places were changed
> > for better structure and the like.
> > 
> > I really don't think, we can maintain a patch against
> > head...
> 
> Particularly at the rate people like me are changing things about... :-)

 [andrew b., this isn't sent you you, btw]

 THE WHOLE POINT OF SPLITTING OUT TO SEPARATE SERVICES IS
 TO MAKE AN UPDATE / CHANGEOVER INDEPENDENT.

 THE WHOLE POINT OF MAKING SEPARATE SERVICES IS TO GET
 SEPARATE MAINTAINERS PER PROGRAM.

 IF YOU CANNOT ACCEPT A TECHNICALLY "INFERIOR" SOLUTION
 TO DRASTICALLY IMPROVE MAINTAINABILITY THEN YOU DON'T DESERVE
 TO CONSIDER YOURSELVES TO BE SO-CALLED "LEADERS" OF THE
 OPEN SOURCE COMMUNITY.

> > At least not with the current available tools in this
> > area...
> 
> For the record, the line I keep hearing is that if somebody comes up
> with a *viable* way to add the required plugablility to HEAD (some kind

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

 this attitude quite clearly must desist: it is stifling
 samba development rather than encouraging it.

 the technical gap is _too large_ to be discouraging people
 from wanting to take part and help out.


> of loadable module support) then it might be possible to work closer on
> the RPC server end of things.
 
 loadable module support is _not_ the way to do it.

 "controlled" from HEAD is not the way to do it.

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

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

 dce/rpc server-programming the programmer expects to have
 total control over their application, and just use an API:

 interface = rpc_ep_register("ncacn_ip_tcp:[]", UUID_of_service);
 rpc_server_listen(interface)
 rpc_unregister(interface);

 link with the library -ldcerpc, and nothing else.

 that way you can have a test server program of 400 lines of code,
 it's understandable, readable, simple, and totally independent.


 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"].

 lkcl