dce/rpc "client" api

[Luke Kenneth Casson Leighton]

> official Debian .deb files for Samba, but also wants some new pipe,
> like exchange on their system. They just copy pipe_exchange.so into
> the Samba lib directory and without even restarting Samba the exchange
> pipe becomes available. 
> 
> One other advantage of this scheme is that it smoothly gives the
> ability for a "bleeding edge" and "stable" version of the pipe
> implementations while using a common smbd.

that's not the case.  as pointed out, earlier, about two or three times,
you remove or modify a definition [of a global or a function] and you're
screwed.

this leaves only two viable alternatives:

- an smbd monolith.

- a compile-time separation of SMB and DCE/RPC service implementations.

i have pointed out the disadvantages of the former approach, already.
perhaps someone could point out to me what the disadvantages of the latter
approach are.

> And we get all this without having to invent a new protocol for smbd
> to talk to external daemons.

*exasperated*

_you_ don't have to "invent a new protocol", it already exists, i wrote it
six months ago, and it works!  [and it went through about three revisions,
the 2nd of which i prefer to the 1st and 3rd, and wish to return to the
2nd revision].

it is also _not_ a new protocol.  it's a transport. it does absolutely
_nothing_ - zero modifications - to the Dce/rpc data it transports.  it
therefore has no effect on any code reviews required of the marshalling /
unmarshalling, zero effect on any code reviews required of the dce/rpc
service implementations.

the ncalrpc domain socket transport implementation is in fact a vastly
_simpler_ codepath to the damn ncacn_np one!  all _it_ does is write() and
read() whilst the damn DCE/RPC over SMB one calls SMBtrans() if it's the
last PDU request fragment, which may or may not require the use of
SMBtranssecondary(), depending on whether the PDU is greater than 2k or
not and also depending on the max SMBtrans data size used, and if there is
more than one PDU request fragment then SMBwriteX() is used, and then if
there is more than one PDU response fragment or if the SMBtrans response
did not return all of the _first_ PDU response fragment, you have to use
SMBreadX().  if you didn't understand all that, or if it's not clear
enough, then that's hardly surprising: it took over two years to work it
out to this extent, and i should also point out that this is a
simplification of the overall process, for the sake of brevity:  i think
it makes a clear enough point.