libmsrpc for Samba 3

[tridge at samba.org]

Tim,

 > The second API should take advantage of the features of the language you
 > are writing the wrappers in.  For example you can accept or return
 > Python lists of strings, instead of a pointer to a unterminated block of
 > SAMR_String structures and a length.

yep, I completely agree, although I would add that I think the 2nd API
should be written on top of the first API, and written directly in the
scripting language, rather than written in C and hooked in.

This keeps the majority of the manual coding (the part not generated
by pidl) in a scripting language which should be easier, and certainly
makes it easier to create an API that suits the language.

This 2nd API is basically what I am creating in scripting/libjs/ for
the js bindings. Notice that it returns nice lists of hashes for
things like user and domain enumeration.

I should also mention that in writing the ejs bindings I have already
hidden some of the details. For example, I expose "struct lsa_String"
as a simple js string, rather than as a structure, and in a similar
fashion I exposed "struct dom_sid" and "struct GUID" as simple strings
using the normal string form of those types. This is one of the big
advantages of pidl over systems like swig - it makes it much easier to
customise some specific mappings when appropriate.

 > The ejs wrappers are interesting in part because there isn't a great
 > deal of richness in terms of language features compared to Python or
 > Perl.

yes, the base language is quite simple, but its well suited to
easy expansion. I also think that being C-like in style is quite a
large advantage given our existing codebase.

I also like some other features:

 - we've been able to integrate it easily with talloc, so we can use
   destructors on objects returned to the scripting language. That
   makes integration with the languages builtin garbage collection
   really nice.

 - the very small base set of functions allows us to more easily add
   functions from our extensive set of C library routines that suit
   our purposes far more than a 'builtin' set of functions would.

The 2nd point you might find strange. The sort of thing I'm thinking
of is the addition of the GetOptions() call, which behaves very
similarly to the perl call of the same name, but knows about the Samba
specific options handling. I suspect it would be quite messy to
integrate our own specialised command line handling code into perl or
python, yet by doing so it means that our js command line tools behave
just like our C tools, which gains us a great deal of consistency.

What I want from js is "a scripting interface to our C code" rather
than a language with Samba add-ons. The heavy lifting and complex code
will continue to be done in C where we have tools like valgrind, good
gcc warnings, stronger type checking and talloc to write really high
quality and efficient code. Yet writing UI code (both web and command
line) and test suites has always been a weakness of C. It's just too
darn tedious so people avoid doing it or do it badly.

I am hoping that with a easy to use scripting language that is backed
by our rather extensive existing C libraries we will see some great
tools built, both within the team and through extensions by users and
administrators.

Of course it might happen that nobody else uses it but me, in which
case I will have wasted a lot of time and effort, but I'm optimistic
that won't happen :-)

The other thing that might happen is we grow beyond what ejs can
provide in terms of language features. If that happens then a fallback
is to move to one of the more complete js engines which do provide
quite a rich language. The obvious choice would be the mozilla
spidermonkey engine, which I believe is ECMA compliant, and which
provides quite a rich language. It's about 10x as much code to embed
as the tiny ejs engine, but it does provide us with an upgrade path if
ejs is too limiting. Using a language that has multiple free
implementations is nice.

Cheers, Tridge