dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Fri Aug 18 05:11:54 GMT 2000
> > ok, then i rephrase: i am proposing the following api
> > in cli_connect.c.
>
> Luke, if this goes into TNG and everyone agrees on it,
> I will merge it into rpcclient in HEAD.
cool.
to disable ncaclrpc, it will then be a matter of commenting out 3 lines of
code.
andrew proposed making it an lp_xxx configureable item.
> I need to keep rpcclient working as it is through the next release
> (and for testing in the meantime)
cool.
well, i am debugging things at the mo (insure is telling me i am freeing
some mem twice).
> > and ncalrpc implementations. because it was not
> > clear, he removed large segments of code, in the
> > interests of simplicity].
>
> So that 'he' would have been me i think :-)
urr... yeh!
> > cli_connect_add() returns a void*. this is the state
> > info required for the connection. each impl.,
> > cli_ncacn_np.c, cli_ncalrpc.c, cli_ncacn_tcp.c etc.
> > will typecast its state to-and-fro. with 8 functions
> > and under 100 lines of code, it is hardly difficult
> > to verify that the typecasts are being done correctly:
>
> I think the void* return value is the only way to
> generically pass back information from the functions
> unless they all share a state information for
> representing a connection.
which is what i wanted to avoid.
> Since you need things like ip_addr and port number
> for a TCP connection and a destination netbios name for
> an SMB connection, you can either (1) put all in the
> information needed to represent all possible
> connection environments (very bad idea),
that's what i used in the first (2nd) rewrite of nmbd. it got so bad that
i decided enough was enough and moved to a void* + 2 callbacks (one for
when a UDP response _Was_ received and one for when a response was not).
so the technique (fn-array + void*-typecast) is pretty predominant in
samba, anyway.
> or (2) return a struct* and the struct contains a void* (same as what
> you have now). Anyone have a good idea of how to do this better?
*shrug*.
More information about the samba-technical
mailing list