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