dce/rpc "client" api

[Sander Striker]

>> I'm not going
>> Jeremy> to re-hash those discussions here - check the mail
>> Jeremy> archives for details. As technical lead and chief architect
>> Jeremy> of Samba it is his decision to make, and I concurr with it.
>> 
>> Hmm, why is this last line always needed? This is clear and
>> I really find this the annoying part (pulling rank) which I
>> was referring to in response to Lukes announcement.
>
>I wasn't trying to be annoying.

I didn't say I found you annoying :^)
I said that I didn't like _the way of pulling rank_, like I also
put in my reaction on Lukes announcement. Also I think it happens
too often (in public, there is often little discussion and then
*bam* there's the decision).

>It's just that we've had
>this discussion, and Andrew made the decision on which way
>we're going to do things. I originally liked Luke's separate
>daemon idea until Andrew pointed out to me the problems with
>is (scalability, reliability etc.) and persuaded me that the
>shared library way is better and will be easier to implement.

Is there any public documentation on this? Could you please
point me to it. (please don't tell me it's in the archives).

>One of the problems when people don't agree is that they
>sometimes try to change a technical decision by bringing
>the same points up over and over again in email, hoping for
>a different outcome (one they like :-).

:-)

>I have a limited time for email, Andrew has stopped responding
>to it entirely (as you may have noticed) and it's this kind
>of re-hashing technical decisions already made that causes
>people to just give up on email. This is very sad, as I personally
>consider it a useful discussion tool - but eventually someone
>has to make a decision, and that person in the Samba Team is
>Andrew.

I know. It's just that this discussion is on a subject that was
discussed, what, 6 months ago? Times change, so do views on
certain problems. With no code in place (or at least an amount
that can be overcome if dropped), decisions can be flexible and
go other ways (or stay the same ofcourse).

>In a way, that last line *was* "pulling rank" - in that
>Andrew (who is the Team Architectural Lead) - had already
>made the decision of "the way it will be" and further email
>on this subject is just a time waster. We need to just get
>coding on it and make it a reality. 

Agreed. I guess the decision on daemons or libraries has
slipped my mind. I think it makes sense to do a publication
of some kind of technical roadmap, at least for HEAD, at
certain intervals (each month?).

Sidenote: although it is important to start coding and stop
discussing, it is also important to, as someone nicely put
it, make a futureproof implementation decision.
We all know Luke as a quick mover and I think we can bet on it
that an endpoint mapper is going to be reality. It would be
wise to take this into account at this point in time.

>Sorry if you found the tone of the email annoying Sander,
>I was just trying to get the discussion back on track as
>to implementation, not going over ground we've covered
>before.

No, that's not what I mean. It's just that this happens on
more occasions and it just doesn't feel right. When someone tells
me a decision is final I can live with that. Others can probably
too. What stings me is the mentioning of Andrews title, which
everyone already knows and (most of the time) respects. If not there
is a discussion, which is good I think.

I'm just a little worried that the way things sound (probably because
the lack of time when answering/writing email) tick more people of
than just me. I think it is really a waste of time for you or other
authorative members to be annoyed by the little things (I'm referring
to a macro issue not so long ago).

As a last statement I would like to say that I am not here to
judge anyone and I hope that everyone takes into account that this
is just my view on things.

Sander