CVS update: tng/source/passdb

[Martin Pool]

On  8 Jan 2002, Luke Kenneth Casson Leighton <lkcl at samba-tng.org> wrote:

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

The situation I was imaging is that if every release for the first
year or so has bugs or unimplemented features it might be too hard for
the hypothetical Exchange client to use, because they'd rather have
their own bugs.  Therefore it's no good for them to use.  

If the only viable customer for the code is Samba, you might as well
make it Samba-specific.

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

Sure, code can be generated from IDL using any existing IDL compiler
and support library.  But from what I understand there is no complete,
free, suitable, well accepted such program.  I'm questioning whether,
if we worked on one, anyone else would use it.

RPC libraries tend to make assumptions about how they will be used.
For example, most that I've seen either make threads optional, or not
supported at all.  (Isn't freedce threaded, and Samba explicitly not
so?)  Most their own method for handling exceptions, allocating
memory, and so on.  If you already have a big chunk of application
code, then there's a good chance it will be incompatible with the
assumptions of the RPC library.

In my experience many people who want to use CORBA have to write a
glue layer to cope with these issues.  GNOME tried out two or three
ORBs (Mico etc) and ended up writing their own (ORBit) because the
existing free implementation didn't fit with the kind of program they
wanted to write.

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

Well, we're talking about implementations here.

> it's in the idllib/ directory.

This is

  cvs -d :pserver:anoncvs at cvs.dcerpc.net:/cvsroot get freedce

right?

Is the documentation correct in asserting that it is all either MIT or
GPL licensed?

FreeDCE being so large is an argument for not rewriting it on a whim.
On the other hand, since Samba in total is smaller than freedce and
therefore obviously only uses a small fraction of the functionality,
it seems silly to add a dependency on such a big chunk.  

I'm a little afraid that if we have to modify the RPC layer to
accomodate M$ wierdness, or evolution since the OSF version was
written, the code would be so big and complex that it might be harder
than starting from scratch and implementing the necessary subset.

Here's something to ponder:

  http://www.joelonsoftware.com/articles/fog0000000007.html

--
Martin