tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Andrew Bartlett]

On Fri, 2012-04-20 at 16:08 +0200, Christian Ambach wrote:
> > Agree. Lets break back compatibility.
> > We need TDB2, but we need a the best TDB2 we can get.
> > Lets not cripple it by imposing semantics or restrictions from the
> > TDB1 API we want to break from.
> >
> > A new api, a new namespace, a new clean start.
> 
> I would push the patch early next week if there are not vetos.
> It disables the building with TDB2 by default so we should not silently 
> stumble across clashing APIs until the TDB2 API has been sorted out.
> 
> The adventurous can still enable it.
> 
> Hopefully Rusty picks this up again soon so we do not see too much 
> bit-rot on TDB2 that in principle is a good idea, but the current 
> implementation and integration seems to cause unnecessary grief.

Given that we have the proposal to move exclusively to TDB2, this seems
like a bad idea, because once removed from autobuild it will quickly
bitrot (and if it doesn't, what do we gain?  This thread started because
tdb2 semantics were in Volker's way).  

Is there an urgency that means we must do this next week?  (I know there
is a delay, but I would still like Rusty to have a say on this, unless
there is a pressing urgent matter that means we must make a move on this
now). 

I know that programming against two similar but not identical interfaces
is a pain, but the work to make the code compatible with both has
already been done.  (that is to not check against -1, and the other
glue). 

We could change to only use tdb1 for the 4.0 release when we branch -
that would have much less impact on our ability to move exclusively to
tdb2 in the future.  However, we are clearly not near the branching
point, and some folks want the features tdb2 brings in a 4.0 release.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org