> Yeah, INN uses it specifically because several of the config files *do*
> have nested structure, and once you've started using it in a few places,
(one, AFAICT)
> it's less confusing for everyone to eventually just standardize on the
> same syntax everywhere. It's sometimes not ideal for the application, but
> I think that's made up for by having consistency.
INN is a special case because of its many inconsistent config files
which badly need restructuring. I'm thinking more of BIND which is a
perfect example of one-level grouping, and has grouping and labelling
done right.
But you're right, best use one common syntax everywhere. What the KDE
people have done right is making a standard library which everyone
uses to access the config files.
> I used to dislike this configuration style because it's fairly verbose,
> compared to unlabelled fields. But after some time maintaining this
> stuff, I've become convinced that the labels on the fields serve an
> important purpose for the person new to the software.
If done right... (why it's not done right in INN belongs on another list).
> The problem I have with this approach is that it only allows one level of
> grouping. So if you look at Kerberos .conf files, you'll find that in
> some cases then ended up needing an additional level of grouping, and so
> you get a hybrid:
>
> | [realms]
> | stanford.edu = {
> | kdc = krb5auth1.stanford.edu:88
> | kdc = krb5auth2.stanford.edu:88
> | kdc = krb5auth3.stanford.edu:88
> | admin_server = krb5-admin.stanford.edu
> | default_domain = stanford.edu
> | }
Ouch. That's really bad. In this case probably they should use one
file called "realms" and make "stanford.edu" a group there, and put
the rest into another file. Or use another format.
> This is a good point to consider, but I've also found that when
> non-programmers try to use those configuration files, they get confused by
> the semicolons and keeping the newline is more intuitive for them. But I
I've just noticed that I have contradicted myself on this point: once
I argued against the semicola and then I favoured folding LF into
LWSP. If doing the latter, the semicola become necessary.
Probably it is less confusing to users to use LFs for delimiter and
make the semicola optional.
This is heading off-topic for the kernel, but I'd like to re-emphasize
that having a common syntax and standard library for parsing these
formats is probably most important. Just keep them human (and "sed")
readable too.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:13 EST