master4-dcerpc-ok

[Andrew Bartlett]

On Wed, 2014-03-19 at 09:45 +0100, Stefan (metze) Metzmacher wrote:

> What about having a #define DCERPC_BINDING_CONNECTION_PREFIX "connection".
> The idea behind this prefix is that, I'd like to have some kind of
> dcerpc_binding_reset(binding, flags) function, which would get a
> flag to reset all connection related options, it would scan the option
> list and remove all options starting with "connection:".

This would be a start at least. 

> In addition I may add a function that replaces dcerpc_binding_dup(),
> instead it would take arguments, which specific which options should
> be copied. As I made dcerpc_pipe->binding const lately, I'd also make
> this private
> and hide dcerpc_pipe completely behind the dcerpc_binding_handle
> abstraction.
> and just have a function (maybe dcerpc_binding_handle_get_binding())
> that also takes the flags arguement and just ask for a copy of the binding
> including the specified options.
> 
> What about having a wrapper function e.g.
> 
> NTSTATUS dcerpc_binding_set_smbXcli_pointers(struct dcerpc_binding *b,
> 					     struct smbXcli_conn *conn,
> 					     struct smbXcli_session *session,
> 					     struct smbXcli_tcon *tcon);

This would be a distinct improvement.

> > The way I read the code, it keeps re-setting the same key-value pair,
> > where "connection" is the key.  I know you better than to assume that is
> > true, but we need the code to be clearer than that. 
> > 
> > Beyond that, I'm not a big fan of these generic functions (and the ones
> > already introduced) that change type-safe specific function pointers
> > that the compiler will check for run-time string based lookups.  I
> > didn't object earlier, but I still don't like it.  The things being
> > passed around here are well known in advance, and having extra functions
> > to set them (even if that means exposing specific types in the generic
> > interface) is still better in my eyes than what we loose in type safety
> > and compiler checking. 
> 
> We could also introduce wrapper functions like
> 
> const char *dcerpc_binding_get_endpoint(const struct dcerpc_binding *b)
> {
>      return dcerpc_binding_get_string_option(b, "endpoint");
> }

This would also be an improvement. 

> But the generic dcerpc_binding_[g|s]et_string_option() functions are needed
> in order to make dcerpc_binding private.

Why can't these helper functions access the private dcerpc_binding?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba