Hi, On Thu, Apr 17, 2003 at 09:45:54AM -0700, Craig Dickson wrote: > Andrew Suffield wrote: > > > On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote: > > > On Thursday 17 April 2003 02:32, Colin Walters wrote: > > > > On Wed, 2003-04-16 at 20:21, Chris Hanson wrote: > > > > > I'd rather fix this properly; what you suggest is a workaround. What > > > > > I consider a proper fix is to redefine the configuration files so that > > > > > they can be parsed. I have learned, the hard way, that using shell > > > > > scripts for configuration files is a bad idea. > > > > > > > > That's true, it's definitely a workaround. The way I did it in > > > > fontconfig is the way I think it should be done in packages which can't > > > > (or can't easily) losslessly parse their configuration files. > > > > > > OTOH, xml config files (like fontconfig's config) could be losslessly parsed > > > through xslt processing... > > > > Much like any other config file can be losslessly parsed by processing > > them. That's not really very helpful. > > Yes, but with a standard format such as XML, you don't have to write > your own code to parse or generate them. > > On the other hand, I don't think we really want package configuration > scripts to require XML tools, do we? Please, no. In most cases, the only feature that's used (and needed) of XML that it stores a tree of attribute/value pairs. Given limited effort, I am absolutely convinced that it should be possible to come up with a more robust, well defined, simple(!), user and implementor-friendly(!), do-one-thing-and-do-it-well way of doing that. Not by starting from "we've got HTML which is being (ab)used for ad-hoc RPC purposes, let's make a more general SGML application to do that" which became XML, but starting from the simple requirement stated above: storing and transmitting nested trees of attribute/value pairs with a *limited* number of possible data types. That means *most definitely not* including a programming language to create all kinds of funky new types, like you have with ASN.1 or the DTDs. If the data types offered are not suitable for your application, there's always octet-string; at least that's my humble opinion. If 5% of the values in a configuration tree remain opaque data, we've already gained 95%; right now configuration files are so brittle and hard to edit losslessly that a lot of them must be treated as fully opaque. Definition should be done like you'd treat a network protocol, with a healty dose of "be conservative in what you write, be liberal in what you read", to paraphrase the great J. Postel, as it /will/ be a protocol, spoken between package configuration scripts and packages. Anybody interested in such an effort? I've got a few ideas for this, but if people feel the current way of doing things is "good enough", then I won't bother you guys with another idea lacking implementation. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpA1Oeq06pOd.pgp
Description: PGP signature