dce/rpc "client" api

[Andrew Tridgell]

> "Samba is just a file/print server and nothing else, nor will
>  it ever be" 

Samba's primary role is as a file and print server. As part of being a
good file and print server in a Microsoft network Samba needs to
implement domain security. If as a side effect of that we can also
implement infrastructure for things like an exchange server then
that's great, but I won't be taking Samba in a direction that makes it
harder to fulfill its role as a file print server to achieve this.

> I would like to know if the intention is to:
>  - drop all ntdom code,
>  - only implement the portion that allows file/printer sharing,
>  - implement all ntdom code in place in TNG.

Sander, I know that you are Luke are deaply irritated that I have not
just taken all your code as-is and put it into a production release of
Samba. If you think for one moment that I don't want a production
release with the ability to be a good domain controller then you are
mistaken. It is my code too, you may not remember but I did quite a
bit of early coding and bug fixing on the ntdom code and I have put a
lot of effort into building appropriate pieces of infrastructure code
etc.

When Luke first proposed his separate daemon architecture to me I told
him that I didn't like it and that I would not accept it. Since then I
have had the argument with him perhaps a dozen times on the phone, in
person and in email. Each time going over the same ground and each
time having to re-explain my reasons. Because I respect the effort he
has put into this I have spent more time explaining things to him than
I think I have ever put into explaining a coding decision before in my
life.

I think the correct approach now is to:

1) implement the shared object loading scheme I outlined in my email
   yesterday

2) generate pipe code from IDL files using a IDL-to-C compiler
   (probably either sidlc or the awk hack).

I have already been over the reasons for (1). The reasons for (2) are
that the current pipe implementations, while impressive, are extremely
fragile. The weeks of effort that JF, Jeremy, Gerald and myself put
into debugging one small piece of that rpc code showed just how
un-maintainable hand-generated rpc code is. It took man-months of
agonising effort after the initial "it works" stage to make that code
reliable, and even now we have something that we all dread having to
debug. Looking back on it I think the effort would probably have been
better spent on writing a spoolss IDL file and working on a IDL-to-C
generator that could handle it.

I know you've put a lot of effort into sidlc, so I know that you also
realise how important it is to move to auto-generated code for the rpc
pipes. I was late in realising this, and I wish I had pushed us in
this direction years ago. 

Of course, you guys don't have to go along with what I say. You are
very welcome to do your own releases of the TNG code (as you have
done) and thus fill the gap that so obviously needs
filling. Alternatively you can do like Luke has done with Cliffs and
start a new project. Either way I will try to support you and offer
advice if you want it.

If, however, you want code to become part of the production releases
of Samba that Jeremy and I do then _please_ have these arguments
before the code is written. It is much less painful for everyone that
way. It has happened far too often that code has been thrown away
because of stupid things that could so easily have been prevented.

Cheers, Tridge