CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Tue, Jan 08, 2002 at 01:33:17PM +1100, Martin Pool wrote:
> On  8 Jan 2002, Luke Kenneth Casson Leighton <lkcl at samba-tng.org> wrote:
> 
> > > 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?
> 
> Perhaps making this concrete might help, though I'm not sure if this
> is the example Luke has in mind:
> 
> Somebody might plausibly want to make GNOME Evolution talk to Exchange
> over rpc, 

yes.  in fact, this has been on the wishlist since 1996, iirc correctly.

> or conversely implement a Unix Exchange replacement.

correct.

> Especially if they were free, Samba developers would probably think
> they are good things, and certainly many Samba users would like to use
> them.
> 
> It seems to me that Luke is arguing that authors of these programs
> would like to avoid writing their own dcerpc implemnetation, because
> it is a large project.  

250,000 lines of code and up.  anyone wishing to do their own
dce/rpc implementation i now deem to be utterly mad.  including
myself.


> On the other hand, they can't use Samba's code
> at the moment because it is too tied to the rest of the program.  One
> example of this is that practically everything depends on loadparm.c.
 
 that is absolutely correct.

> It might be nice if the code to do dcerpc was less coupled to Samba,
> so that it can be reused to help such good causes.  So Evolution can
> link to libsambadce or whatever, and share code maintenance.  (In
> fact, it looks like it would probably be a library plus code
> generator, like most RPC systems.)
> 
> Once you've made that split, you could perhaps refactor Samba to use
> the library from several different processes.  That seems like a
> secondary point, and simply a matter of taste for Samba developers.

correct.

> I don't know the code nearly well enough to say whether it could be
> done, and certainly refactoring Samba for the benefit of other
> projects (which don't apparently exist yet) is a lot to ask.
> 
> Potential downsides are numerous:
> 
>  - The library needs to have a stable interface, which limits our
>    ability to evolve it.  

it's quite simple, in fact.  i've been thinking about this interface
for several months over the last three to four years, so we
stand a good chance of getting it right first time.

if not, versioning / support (like 2-stage SMB CAPABILITIES
negotiation) could be added, which makes it a future-proof interface.

>  Also to be useful it must be more thoroughly
>    documented than an internal interface, which will take effort.
 
 yep.

>  - For various reasons (licensing, control, threading, ...), other
>    projects might choose not to use this library anyhow, so the work
>    of separating it would be wasted.
 
 not true.  the publication and release as an rfc of an IDL file
 as the specification would allow both the client-side 
 and server-side implementation
 of the parser needed to be generated in seconds, on modern
 platforms, using freedce or any other dce/rpc IDL compiler
 environment.

>  - Clean interfaces are sometimes slower than tightly coupled ones.
>    Since some silly people do care about benchmarks this might be a
>    problem. 
> 
>  - It might not be possible to write a clean interface to dcerpc,
>    because of cross-layer coupling - e.g. authentication carried out
>    at different levels of the stack, etc.

that's implementation specific.

> I'm having a look at NDR DCE/RPC code generation at the moment, and
> will try to keep whatever I write reasonably modular.  Whether anybody
> will actually use it I don't know.

great.

it's in the idllib/ directory.

talk to wez furlong, he's familiar with the code.

good luck!

btw, i should point out that if an IDL file is used, then
you can either:

- hand-code it like i did [mad!!!]

- use aparser the awk auto-generator that andrew developedd

- use freedce's dceidl compiler.

- even use MIDL.EXE!

any of these approaches is perfectly acceptable and valid.

and now i _have_ to go: some people are depending on me
in cambridge for materials and i was up late last night
doing email.

i lose money and time dealing with this stuff if those
people stand around on their thumbs or worse, go out to
the pub.

lkcl