summary [was Re: dce/rpc "client" api]
Gerald Carter
gcarter at valinux.com
Wed Aug 23 01:46:25 GMT 2000
"Mayers, Philip J" wrote:
>
> So, to summarise (correct me if I'm wrong)
>
> 1) DCE/RPC has (mostly) a transport-independent structure
> for it's PDUs. Luke favours the creation of a
> generic, transport-independent library for marshalling,
> unmarshalling, endpoint-mapping, authentication/encryption, and
> all the services associated with the RPC runtime under Win32
Correct. And I will add this is a wonderful idea itself.
It should not be tide to Samba at all. If it matures,
Samba could migrate to it. It's just not going
to happen right now as Andrew has said.
> 2) Jeremy, Andrew (and optionally others), for *Samba*,
> favour implementation of per-data type marshalling
> functions, using the service implementation code from
> TNG. This would allow them to marshall to/from SMB,
> and pass full RPC PDU's to/from dynamically-loaded
> modules, which actually *implement* the services.
Yes.
> Would it be possible to write an RPC library with
> optional hooks in it. That way, Samba could (in the
> future, after 3.x has stabilised, if the developers
> want to) use that library/IDL-compiler, and hook in
> at the points between 1/2 and 3/4 (or 2/3). Other
> services, like our hypothetical "Exchange" server, could
> let the RPC runtime handle the network stream level and
> optionally everything right up to calling the
> implementation functions.
Once the dce/rpc development api stabilized (matured),
this might be an option.
Notice that Luke has been fairly quiet (in the grand
flood of mail). :-) Luke????? Where are you????
Cheers, jerry
----------------------------------------------------------------------
/\ Gerald (Jerry) Carter Professional Services
\/ http://www.valinux.com VA Linux Systems gcarter at valinux.com
http://www.samba.org SAMBA Team jerry at samba.org
http://www.eng.auburn.edu/~cartegw
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
More information about the samba-technical
mailing list