Avoiding further (LDAP) stack proliferation in Samba

[Jeremy Allison]

On Thu, May 21, 2020 at 01:53:36PM +1200, Andrew Bartlett wrote:
> On Wed, 2020-05-20 at 18:21 -0700, Jeremy Allison via samba-technical
> > 
> > Are there tevent_req async versions of ldb_search() and ldb_request()
> > (haven't looked, don't have the time right now, sorry) ? If not, is
> > is easy to add them ?
> 
> No, and I've been told that gluing the two different async
> architectures together isn't trivial, but it would be worth someone who
> really understands (or perhaps the opposite, someone who doesn't and so
> doesn't know what is impossible?) having a red hot go.  
> 
> Thankfully in this case all the calls are synchronous (some with
> callbacks), none return to the main event loop, so this doesn't impact
> this use case.  This is why I suggested ldb_search() and ldb_request()
> would be a good match.
> 
> > New code is moving to tevent_req and async as much as possible, so
> > to standardize on an internal ldap stack - which would be an
> > amazingly
> > good thing to do IMHO it needs to have tevent_req and async
> > functionality
> > I think.
> 
> It may be that we are unwilling to commit to the use of LDB if there
> isn't a clear path to being able to use tevent_req in the future.  
> 
> In that case, all I would ask is that we do other things to merge the
> stacks first, for example:
>  - have LDB use more common layers with tldap under the hood.  Some
> ASN.1 parsing is shared, but there is a lot that is not.
>  - have tldap and LDB share structures (and so helper functions) like
> ldb_message and ldb_dn
>  - have common ASN.1 parsing for controls
>  - do likewise with the smbldap code and libads.
> 
> Currently we have at least thee different ways an LDAP search response
> is expressed, for example.  This makes it harder to have common utility
> functions.
> 
> Imagine if we could prepare a struct ldb_request, but instead of
> passing it to ldb, we pass it to (say) tldap, and the responses are
> again ldb stuctures that we can use ldb utility functions on?  
> 
> This would work around the existing non-tevent async architecture of
> LDB but still avoid all the collateral duplication (which is my bigger
> concern).
> 
> I know I'm asking a lot, but as I said, unless we pause now and plan
> the later merge work becomes quite epic.

That sounds like a sensible plan to me, but having said
that I'm not going to be the one doing the work :-).

As we as a community have decided tevent_req is "The Way"
then helping our older stacks integrate better with it
is certainly a good way to make progress IMHO (and I'm
as guilty as anyone as the author of the horrible hack inside smbd
to do async opens which sidesteps tevent_req in order
to reduce code changes).