configuration, ldap and NetInfo
Robert Frank
frank at ifi.unibas.ch
Fri Apr 17 18:07:46 GMT 1998
> > 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 :}
Okay, so I don't know the details of SWAT (and won't because NExT/Apple
use OPENSTEP which is based on display postscript, not X windows), but, of
course, you could always simply use a function which only returns the
defaults ..., regardles of what else happend within samba. But, anyway, you
seem to need that stuff, so leave it. It just consumes a little bit more
memory.
> > 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.
Just after submitting my comment I thought better of it. The need of new
access functions is obvious, so the rest might just as well be with a new
type too.
> > 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?
In all cases where the separator is white space yes! But I remember two
cases which used a '/' (alas, I'd have to lookup which paramaters) - that
should be eliminated, although it will cause several people headaches if
they don't edit smb.conf ...
A side not: I'll be away until next Wednesday.
-Robert
-------------------------------------
Institut fuer Informatik tel +41 (0)61 321 99 67
Universitaet Basel fax. +41 (0)61 321 99 15
Robert Frank
Mittlere Strasse 142 rfc822: frank at ifi.unibas.ch (NeXT,MIME mail ok)
CH-4056 Basel (remove any no_spam_ from my return address)
Switzerland
More information about the samba-technical
mailing list