Extending LDB for Extended DNs

[Stefan (metze) Metzmacher]

Andrew Bartlett schrieb:
> On Tue, 2008-12-16 at 06:03 +0100, Stefan (metze) Metzmacher wrote:
>> Andrew Bartlett schrieb:
>>> On Mon, 2008-12-15 at 13:46 -0500, simo wrote:
>>>> On Mon, 2008-12-15 at 19:39 +0100, Stefan (metze) Metzmacher wrote:
>>>>> Andrew Bartlett schrieb:
>>>>>> On Fri, 2008-12-12 at 12:35 +0100, Stefan (metze) Metzmacher wrote:
>>>>>>> Andrew Bartlett schrieb:
>>>>>>>> On Wed, 2008-12-03 at 13:38 +1100, Andrew Bartlett wrote:
>>>>>>>>> On Tue, 2008-12-02 at 21:21 -0500, simo wrote:
>>>>>>>>>> On Wed, 2008-12-03 at 11:35 +1100, Andrew Bartlett wrote:
>>>>>>>>>>> On Fri, 2008-11-21 at 18:28 +1100, Andrew Bartlett wrote:
>>>>>>>>>>>> On Fri, 2008-11-14 at 18:23 +1100, Andrew Bartlett wrote:
>>>>>>>>>>>>> On Wed, 2008-11-05 at 22:33 +1100, Andrew Bartlett wrote:
>>>>>>>>>>>>>> Great.  I've been working on this hard for the past week or so.  See
>>>>>>>>>>>>>> http://gitweb.samba.org/?p=abartlet/samba.git/.git;a=shortlog for the
>>>>>>>>>>>>>> current work in progress.
>>>>>>>> I've just updated this tree again.
>>>>>>>>
>>>>>>>>>> Anyway I would not put it in if it is going to break the LDAP backend,
>>>>>>>>>> we should have it working for.
>>>>>>>>>> I have gone through great pain myself to make sure my stuff did work
>>>>>>>>>> with LDAP with the async patches, is there a reason to apply a different
>>>>>>>>>> standard in this case ?
>>>>>>>>> No, there isn't, and you are right to hold me to that standard.  I'm
>>>>>>>>> working on the changes to allow this to work with OpenLDAP's dereference
>>>>>>>>> control right now.  
>>>>>>>> I've updated my tree, and with some small changes to ldb
>>>>>>>> (ldb_module_send_entry() now takes a control parameter) and a lot of
>>>>>>>> other work on modules and control parsing, it all works!
>>>>>>>>
>>>>>>>> I would like to merge the above tree into 'master'. 
>>>>>>>>
>>>>>>>> Any comments?
>>>>>>> I'll review your stuff over the weekend.
>>>>>> I'll brace myself :-)
>>>>>>
>>>>>> But seriously, while I know it will mean more work for me, I do
>>>>>> appreciate your reviews.
>>>>> I didn't looked at as close as I wished, as it's not that easy to
>>>>> review with all the merges and bug fix commits.
>>>>>
>>>>> But I think you should push it to master.
>>>> It would be nice to see a clear diff before the push at least.
>>> See attached.  (I've skipped the regenerated swig files)
>>>
>>>> I personally would also like a rebase much more, but our samba git is
>>>> cluttered enough already that probably it won't make much difference in
>>>> the noise :-(
>>> I agree. 
>>>
>>> Andrew Bartlett
>>>
>>>
>> I think extended_dn_out_dereference.c and extended_dn_out_ldb.c should
>> be left out.
> 
> Oops.  As you can see, I was able to consolidate these into a single
> file.
> 
>> Also the rpc_server/dcerpc_server.c should be on its own.
> 
> Oops, I had tried to split that out.  I wonder what happened..
> 
>> BTW: why is that needed? why should we return an assoc_group_id
>>      if we didn't find the interface the client asked for?
> 
> Only because windows returns a non-zero here.
> 
>> If possible I'd like to see multiple commits for the rest:
>> 1.) add the extended dn handling into ldb_dn.c + headers + tests
>>     (I assume this only adds new functions and no existing caller
>>      needs to be changed)
>> 2.) add controls per entry support.
>> 3.) all the code that splits out ldap_decode_attribs_bare()
>> 4.) the new ldb modules and required provision changes
>> 5.) the new/modified tests for the new functionality of the new modules
> 
> Would it be aright to just do the merge?  I can't see easily how to
> split for example the new ldb modules from the extended dn handling and
> the adding of controls per entry.  Certainly I can try and cherry-pick
> the ldap_decode_attribs_bare change (and the new control), but without
> reworking the rest I don't think it helps.

You could make use of git add -i and select only parts of the hunks
for commit.

git add -i (and there the 'patch', 'update', 'add untracked' or 'revert'
            commands, they all only work on the 'index'/staging area
            so 'revert' will only unstage the changes, if you staged
            a patch hunk to much, use 'revert' for the file and redo the
            'patch command)
git diff --cached -p --stat (to review what will be in the next commit)
git diff -p --stat (to review what will not be in the next commit)
git commit

repeat that until everything is commited.

Maybe it's not possible to split it into 5 commits, just try the maximum
that's possible without doing much manual work.

(I'd still prefer one or two commit instead of doing a git merge.)

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20081216/50f5c073/signature.bin