libmsrpc for Samba 3

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tridge at samba.org wrote:

| There are similarities between the two approaches,
| but one is not based on the other. The API in Samba4
| is based directly on the IDL files.

I meant to say "basically", not "based".  I'll blame that
one my my spell checker.  If anything, I've stolen from
Samba 4. :-)

| So to make the above call a client does this:
|
| 	struct svcctl_EnumServicesStatusW io;
|
| io.in.handle = h;
| io.in.type = SERVICE_TYPE_WIN32;
| io.in.state = SERVICE_STATE_ALL;
| io.in.buf_size = 0;
| io.in.resume_handle = &resume_handle;
| io.out.resume_handle = &resume_handle;
|
| status = dcerpc_svcctl_EnumServicesStatusW(p, mem_ctx, &io);
|
| At first you might think it is easier to have a
| conventional function interface, and have a win32 style
| function with 8 parameters, but I have found that it
| is in fact much easier to program with the in.* and
| out.* interface than the win32 style interface.
| The reason is that with so many parameters of the same
| type it is incredibly easy to get the call mixed up.
| By explicitly naming the parameters as you set them
| you end up with much less error prone code.

Yeah.  I can see this.  I'm still thinking about it.

| Unless you adopted the auto-generated code from pidl
| I think it would be a huge task to make a new rpc
| library for Samba3 be compatible with the Samba4 API.
| What you perhaps could do is make the APIs as close as
| possible so that it is less painful for users of the
| library to transition between the two.
....
| I don't think there is any question that the
| future of RPC in Samba has got to be based on
| auto-generation from IDL.

I agree about the importance of IDL.  But I'm still
thinking about your proposal.  You are calling the
client API the point at which structures get [un]marshalled.

In Samba 3, I have this:

WERROR cli_spoolss_open_printer_ex( struct cli_state *cli, ....)
{
	....
~        make_spoolss_q_open_printer_ex( &in, printername, datatype,
		access_required, station, username );

	CLI_DO_RPC( cli, mem_ctx, PI_SPOOLSS, SPOOLSS_OPENPRINTEREX,
	            in, out,
	            qbuf, rbuf,
	            spoolss_io_q_open_printer_ex,
	            spoolss_io_r_open_printer_ex,
	            WERR_GENERAL_FAILURE );

	memcpy( pol, &out.handle, sizeof(POLICY_HND) );

	return out.status;
}

The make_spoolss_q_open_printer_ex() call does what you
do by assigning the structure elements necessary for
the outgoing call.  So what you call the client interface
the the CLI_DO_RPC macro I've used above.

This is the cooresponding code from Samba 4:

	op.in.printername       = talloc_asprintf(ctx,
				  "\\\\%s",
				  dcerpc_server_name(ctx->p));
	op.in.datatype          = NULL;
	op.in.devmode_ctr.devmode= NULL;
	op.in.access_mask       = 0;
	op.out.handle           = &ctx->server_handle;

	status = dcerpc_spoolss_OpenPrinter(ctx->p, ctx, &op);

What I'm still considering is whether or not this
low level API is really best for application writers.
I'm just not totally convinced yet, but am still thinking
about it.  Parts of it I like but parts of it I'm still
pondering.  At least now I do know that I understand your
original suggestion.

Chris, You want to weigh in here ?  Got any observations
or comments?




cheers, jerry
=====================================================================
Alleviating the pain of Windows(tm)      ------- http://www.samba.org
GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
"I never saved anything for the swim back."     Ethan Hawk in Gattaca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3k5lIR7qMdg1EfYRApQxAKCoAb85eYiHcMXHh3DgTOcakbZS5wCfZhCk
jnYxSmwV0liqzpidiK1/75c=
=cwIm
-----END PGP SIGNATURE-----