a proposal for Samba 3.5

[Luke Kenneth Casson Leighton]

> >btw if you're looking for test code for the Sam* functions, take
> >a look at razor.bindview.com.

> Also, see samba4/source/torture/rpc/samr.c.

hiya luke, good to hear you're still around.

your reference to this code is useful because it prompts me to
clarify the point i am making.

the code you refer to above is, whilst it is very similar to
the Win32 / Undocumented-SAM API, is 

the point i am making is that whilst you're in the process of
developing an API, why not develop one that is identical to
the Win32 / Undocumented-SAM API, and in the process you will
gain:

a) a lot of code to test your API with, unmodified.

b) a lot of kudos.

c) a lot of programs, if you go one step further and create a 
binary-compatible interface (combine with wine), to test
_programs_ unmodified.

todd sabin's SAMr and LSA testing code falls into category a)

USRMGR.EXE falls into category c)

the code at samba4/source/torture/rpc/samr.c falls into category
d) - internal test code which will ultimately suffer the same fate
as rpcclient.

which leads me to consider the possibility that, consciously or
subconsciously, one of the less valid reasons why rpcclient is
not going to be maintained is simply because i hold the copyright
on it, and that's too much for the samba maintainers andrew and
jeremy to live with.

... but there are plenty of _valid_ reasons why rpcclient should
be phased out that make up for such: hand-crafted RPC code is a
complete bitch to work with beyond the learning curve stage.

l.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl at lkcl.net"> lkcl at lkcl.net </a> <br />