dce/rpc "client" api

[Sander Striker]

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

This I can understand. I am just at the point where I ask if it
is going to be harder to fulfill this role. Let me explain:
If implementing dce/rpc as a toolkit (minimal at first) makes it easier
to implement the required rpc services samba needs, why not put in the
effort? If this is not done right now, it will mean that in the
(near) future a piece of the samba codebase has to be replaced. That
would be a waste of effort. That's the point I'm trying to make.

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

Well, I am a little irritated when it comes to dismissing it all.
I only did a small portion of coding on TNG, but I do feel emotionally
attached. Maybe because I like the design. Maybe because its just
a lot of code (that actually works). I've seen a lot of effort being
put into it (even now).

Next I don't think it's just me and Luke, I think it's bigger. But then
again I don't really know.

I'm not implying that you don't want a production release with the
ability to be a good DC; I'm just taking the bait that someone threw
in the ring, namely that samba is a file and print server, not aimed
to do more than provide file and printer sharing. I interpreted it
like: samba is a file and print server and we will only implement
dc code that is needed to serve file and print serving needs. Nothing
more.

I think it is also not the idea to tick anyone off when it comes to
put in effort. Everyone respects eachothers contribution (correct me
if I'm wrong). I know code should be reviewed (that's a good thing)
and I know design has to be reviewed (also a good thing). But I don't
think it's a good idea to implement something twice if it has been
done right (especially when this is done because someone doesn't
understand the code <- this has actually happened).

>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 really think that this is appreciated. It is important to take time
for eachother when it comes to these decisions. It must be hard to
dismiss a lot of code. 

>I think the correct approach now is to:
>
>1) implement the shared object loading scheme I outlined in my email
>   yesterday

Right. I think this is going to be a job for the people supporting it
because they probably have the motivation to do so. I think it is wise
to consult the 'opposing camp' in this, to provide somekind of
'co-existence interface'.

Sidenote: Please do these kind of postings on a regular basis.

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

Yes, this is what I've been trying to say. And when you look at it,
sidlc would be just a small piece of the puzzle (as part of the
minimal dce/rpc toolkit).

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

Well, I haven't been around long enough to do 'the right suggestions',
I still have to get to know everyone and there roles.
I did put some effort into sidlc, but when everybode started to use
aparser, my motivation was mostly gone. Elrond and Luke did try to
get me to continue again, but I need to do this in a group, not as
a lone coder. It's not that I can't, it's just not very motivating.
I even started to do a bit of memory management coding for TNG to
speed things up.
If we want to get things moving again, we've got to get our stories
straight. I need help doing sidlc (it's big, it's fat, it's ugly).
Also, I don't know which direction this is going. Is it going to
be part of a dce/rpc toolkit or is it going to be something else?
I really don't know.

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

I very much appreciate this. I think TNG needs to be supported until
there is a production release of DC code. This gap needs to stay
filled, otherwise people have to go back to MS servers...

Sidenote: I think cliffs was just Lukes way of showing that it could
be done; nothing more, nothing less.

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

I totally agree. However I would still like to point out that although
things can be discussed today, it could look completely different in
three to six months. Since the project has become so big, I think it
is very important to 'do things by the book' whenever possible.
And in reaction to Pierre-Jules Tremblay I would like to say that it
is indeed better to do these discussions in public. This isn't really
needed when all participants agree on some subject, but when this is
the case, a posting about the outcome should be made. I know this
would take time, but it would be worth it.

Sander