tldap search paged

[Christof Schmitt]

On Thu, Apr 09, 2020 at 06:05:06PM +0200, swen via samba-technical wrote:
> On Wed, 2020-04-08 at 10:19 -0700, Jeremy Allison wrote:
> > On Wed, Apr 08, 2020 at 07:07:57PM +0200, swen wrote:
> > > On Wed, 2020-04-08 at 09:07 -0700, Jeremy Allison wrote:
> > > > You haven't explained *why* you need this code.
> > > Hmm sorry, I thought I did say that I'm in the process of creating
> > > a
> > > winbindd_ldap which is supposed to replace winbindd_ads.
> > 
> > Can you start with explaining your overall design
> > for this, rather than diving into low-level coding.
> > 
> The base goal is to lay the foundation for a series
> of winbind improvements.
> The replacement of the ADS-API in winbindd by the tldap library
> is just
> the first step.
> 
> Further goals in this area are:
> 
> - Improve the failover times for disappeared DC
> 
> - optimize the kerberos ticket handling in such a way that 
>   existing
> tickets are used instead of triggering a new auth request
> 
> - centralize the DC connection management to support a reliable and 
>  
> fast detection of connection loss and reconnection process
> 
> - integrate and condense the required code and functionality to
>   a minimum number of layers and remove APIs and layers not required.
> 
> As a first step we decided to align the ldap libraries and
> move the
> functionality, included in winbindd_ads.c,
> to use the tldap library.
> 
> Since we didn't want to reinvent the wheel we started using the 
> functio
> nality offered by the tldap-/tldap_util-library which does offer
> already a few of the required features.
> 
> As a starting point of this first step, we replace each externally 
> trig
> gered function (callbacks) from the winbindd_ads.c 
> by pure-ldap
> versions.
> Not only that this is the least invasive approach but it eases the 
> test
> ing as the results and timings are easy to compare.
> 
> I hope this explains things and motivates you all to support the small
> modifications suggested by my patch-set.

Since the proposed merge request is only one piece, it probably does not
make much sense to just merge this individually. Gitlab has the
convention of tagging "work in progress" as WIP. What about the idea of
marking the merge request as "WIP", and you continue working on the MR.
If more patches are ready for review, you can update the WIP merge
request, ask for feedback and then adjust. Once individual patches look
good, they can be tagged with "Reviewed-by". When the rework is complete
and we see the proposed API changes, the API usage and ideally test
coverage, we can do a final review and merge. Does that sound like a
possible way forward?

Christof