configuration, ldap and NetInfo

[Andrew Tridgell]

> Little missunderstanding here, If you put the defaults into the 'current'  
> value and have the boolean 'default' set to true, then that is the default  
> value. Once a parameter is read (or set otherwise), the boolean is set to  
> false. Viola, you know its no longer the default value.

unfortunately that doesn't work :}

> > The union stores the default value after defaults are initialised. It
> > allows SWAT and testparm to print only those values that are different
> > from the default. That makes for small and readable config files.
> The boolean will allow exactly the same, but it occupies only one storage  
> location (a string uses more).

nope. With the boolean you only know the default value when another
value hasn't been loaded from the conf file. With the union you know
what the default is *after* you have loaded the conf file. The
difference is v important as without it you can't produce the minimal
smb.conf from the loaded smb.conf.

I actually thought the same way you did at first, and even implemented
it that way. Then I realised why it can't work and I redid it with the
union :}

> Do we need a new *type* or would a flag suffice (allowing ints to be lists  
> too)?

I think a new type is best, otherwise we would get in real trouble
with the return type of the access functions. A access fn (ie. a lp_
function) for a P_STYPE would return (char **) whereas P_STRING
returns (char *). I know we could use piles of casts, but that would
be pretty horrible.

If we need lists of ints then a P_ILIST would be added as well. They
could share code in the list parsing, but would be distinct types in
loadparm. 

Remember that type system in loadparm is partly there to make coding
mistakes much harder. It allows for fairly strict type checking to be
done by the compiler. 

> That this doesn't require any changes in the conf syntax is per se
> correct, but my other examples of parsing show that we would be in
> trouble under certain (common!) cases.

hmmm, I'm not at all convinced. Doesn't the " handling in next_token()
plus the list stuff address your concerns?

Cheers, Andrew