auto-generated MSRPC backends

[tridge at samba.org]

Simo,

 > Any chance to know the plans? I'm very interested in the SAM field, and
 > would be happy to help you out on that.

It's the automated database backend stuff I have mentioned a few
times. The SAM is just a database interface, as are most of the calls
on most of the MSRPC pipes. The idea is to auto-generate code that
maps from the MSRPC structures (which are themselves auto-generated
from IDL by pidl) onto various database backends. 

Lets take LDAP for example. I want to write a code generator that
takes a complex structure or union defined in IDL and generate two
functions. The first function will make an LDAP query that will fill
that structure and the second will make an LDAP query that will push
the values from the structure into the LDAP database.

In order to do this the generator will need to be told a few things:

 * the field names in the database, if they differ from the field
   names in IDL

 * where in the database hierarchy the structure is stored. I'm yet to
   decide if this will be derived from annotations in IDL or a
   separate abstract schema file.

 * what authorization needs to be performed. I'll probably skip this
   in the first pass until I work out a good credentials structure to
   use for Samba4.

So we will end up with something like this in rpc_server/srv_samr.c:

   NTSTATUS samr_SetUserInfo(struct dcerpc_state *state, struct samr_SetUserInfo *r)
   {
	return dcerpc_db_set_union(state,
				   r->in.handle, 
				   r->in.level, 
				   (db_set_union_fn_t)dcerpc_db_set_samr_UserInfo,
				   r->in.info);
   }

and dcerpc_db_set_samr_UserInfo() will be an auto-generated function
that produces the necessary database query code for the various
backends (SQL, LDAP, TDB etc). That function will be generated by
pidl, and will do all of the necessary policy handle validation,
authorization, field name translation and error handling.

Internally, dcerpc_db_set_union() will need to map from the policy
handle to a database handle, and that database handle will contain
methods for the various database types.

So, many of the MSRPC server side functions will just be a few lines
of hand written code, with the rest auto-generated. It's possible that
we will move to auto-generating those few lines of code as well,
although the lack of consistency in the interface form may prevent
that. 

Hopefully this gives you an idea of where I am heading with all
this. The big thing to notice is that we will not need to write
separate lumps of code per info-level with a big switch statement. We
also won't need to write lumps of code per-field in each
structure. All we need to write is a tiny bit of glue code.

Cheers, Tridge