CVS update: tng/source/passdb
mbp at samba.org
Mon Jan 7 18:34:14 GMT 2002
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
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, or conversely implement a Unix Exchange replacement.
Especially if they were free, Samba developers would probably think
they are good things, and certainly many Samba users would like to use
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. 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.
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.
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. Also to be useful it must be more thoroughly
documented than an internal interface, which will take effort.
- 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.
- Clean interfaces are sometimes slower than tightly coupled ones.
Since some silly people do care about benchmarks this might be a
- 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.
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.
More information about the samba-technical