|
From: Rich M. <ric...@gm...> - 2011-03-01 20:37:20
|
On 03/01/2011 01:13 PM, Michael Ströder wrote: > Rich Megginson wrote: >> About the arguments and return values to result4 - with the current code >> I have to do something like this: >> >> rtype, rdata, rmsgid, decoded_serverctrls, extop_rspoid, >> extop_rspval = srv.result4(msgid, 0, -1, 1) >> >> That is, I only want the decoded_serverctrls, but I have to add items >> for extop_rspoid and extop_rspval even though I don't want them, because >> result4 always returns a 6-tuple, regardless of what the caller wants. >> Maybe this is the convention, to have to provide all of the optional >> return values, to make it consistent that result4 always returns a >> 6-tuple? Because it would be pretty easy for result4 to look at its >> arguments and do something like: >> if add_extop: >> return a 6-tuple >> else: >> return a 4-tuple > Look at the convenience wrapper method LDAPObject.extop_result() I've added > recently. A similar method could be easily added for the case where the caller > knows that one does not expect a ext op result. I consider this to be a more > readable approach than looking at an argument. Ok. Sounds good. > More ideas: I'd like to let the result-methods decode the response controls > and ext op responses received. I'm thinking of adding a new optional keyword > argument where one can pass in a dict([oid:class]) which can be used to > automagically let the result method return instances of LDAPControl or > ExtendedResponse. > > I'm also thinking about splitting LDAPControl into RequestControl and > ResponseControl. Both good ideas. > More comments welcome. > > Ciao, Michael. |