[samba-tng] spoolss conversion is complete!

[Luke Kenneth Casson Leighton]

On Sat, 29 Jan 2000, Jean Francois Micouleau wrote:

> 
> On Sat, 29 Jan 2000, Luke Kenneth Casson Leighton wrote:
> 
> > ... i didn't say it would work, though :)
> > 
> > jean-francois, if you need any "state" information, e.g a
> > connection_struct, then we're going  to have to do this:
> 
> nope. connection_struct are useless in the rpc code. well in the global
> case, maybe in 1 or 2 cases ??? But not required for the spoolss.

excellent!
 
> > equivalent to what you were doing, anyway, plus i didn't have to think
> > about the horrible implications of trying to set up spoolssd
> > printer-shares the same way as the smbd spawned-process euugh.
> 
> the spoolss code needs to get a list of 'lp_printable()==ok' shares
> including the [printers] one. that's all.

ah.  then what about all the standard_sub() calls that it makes down
through nt_printing.c into printing.c?
 
> 
> Hum well, just something. I've got your idea of splitting the rpc code
> into seperate daemons from smbd, it has a lot of pros, it's an old project
> you had (we talked of that almost 2 years ago at CB1).

you know... yeah, i'd forgotten about that.  good memory.  all i remember
of that visit is it was cold on the roof!


 
> But I really don't get your last 2 weeks work ! Is anybody on this
> list able to explain why splitting the rpc server code is cool ? something
> *really* necessary ? a must have for samba ?

jean-francois, i very rarely stick to the "necessary".

1) it's so that other people can write alternative implementations
(including me!) _without_ having to worry about marshalling and
unmarshalling.  why should they???

2) we can replace the marshalling code with auto-generated code.

3) it's possible to write stubs like this, for use as dynamic-runtime
loading:

spoolss_open(...)
{
	return _spoolss_open(...)
}

...
...

that way, if i convert all the smbd code (e.g domain_client_validate()) to
use client-side msrpc functions, i can convince andrew (i hope!) to use it
in cvs main, because you either load (dynamically) this:

dlopen("samrloopback.so")

or this:

dlopen("samrmarshall.so")

the samrloopback.so contains this:

samr_open(...)
{
	return _samr_open(...)
}

...
...


while the samrmashall.so contains rpc_client/cli_samr.c and what is now
rpc_server/srv_samr.c.



you get the idea?