The Wrapper Project

Jeremy Allison jra at samba.org
Mon Dec 2 15:33:55 MST 2013


On Mon, Dec 02, 2013 at 10:27:32PM +0000, Jelmer Vernooij wrote:
> On Mon, Dec 02, 2013 at 02:23:43PM -0800, Jeremy Allison wrote:
> > On Mon, Dec 02, 2013 at 09:43:22PM +0000, Jelmer Vernooij wrote:
> > > On Mon, Dec 02, 2013 at 01:21:04PM -0800, Jeremy Allison wrote:
> > > > On Fri, Nov 29, 2013 at 12:15:08PM -0500, Simo wrote:
> > > > > 
> > > > > The point is that we are not good at maintaining external code once you
> > > > > suck it in the tree.
> > > > 
> > > > IMHO The point Simo is making above is the most important
> > > > one in this discussion.
> > > > 
> > > > We have pulled in external code, Heimdal, popt, zlib
> > > > and WE DON'T KEEP IT UP TO DATE.
> > > 
> > > That is a different class of libraries. These three libraries were internal to
> > > Samba; they're more akin to e.g. tdb, talloc. tevent or ldb.
> > 
> > Heimdal I'm willing to concede as we needed to make
> > changes to make the AD-DC. But are we done there ?
> > Shouldn't we be pushing upstream ?
> 
> The three libraries I'm talking about are the ones that Andreas has
> split out of the Samba tree - socket_wrapper, uid_wrapper and
> nss_wrapper. They're the same category as tdb, talloc, tevent and ldb
> as they were originally internal to Samba.

Doh, sorry - EREADERTOOSTUPID :-).

But I'd still argue that if they're going to be
made generic and used by other projects that
the ultimate goal should be to spin them off
into a separate tree. That way the interfaces
get more review (due to the needs of other
projects) and tend to improve and become
more generic over time.

I think it does lead ultimately to better
code - it forces us to think more about
how to interface with things rather than
just being able to make arbitrary changes.

The only question I have is are these
libraries ready to make that step ? We
tried with ctdb and this eventually had
to come back. I'd argue we've been better
with talloc, tdb and tevent.

Jeremy.


More information about the samba-technical mailing list