Date: Tue, 27 Mar 2001 18:19:41 +1000 (EST) From: Andrew Reilly <areilly@bigpond.net.au> To: jkh@osd.bsdi.com Cc: Cy.Schubert@uumail.gov.bc.ca, jar@integratus.com, jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML? Message-ID: <20010327081943.EE95A37B718@hub.freebsd.org> In-Reply-To: <20010326234129J.jkh@osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Mar, Jordan Hubbard wrote: > To put it somewhat more succinctly, I think we're all pretty wedded to > our ways and only accept change when it's a significant order of > magnitude improvement beyond what we currently have or it doesn't > conflict with any existing scenario. Thus Unix slowly accretes > functionality to itself without changing shape too much. :) OK. I'm probably not alone in thinking that that's a bit of a limiting position, but I understand the arguments, and they're good. The compatability issue is big and important, and makes things significantly harder, but not impossible. It ought to still be possible to define a libconfig API that contains a set of access mechanisms that provide the functionality required by the standard tools, if not necessarily the form. Trouble is that the initial, default implementation has to be clever/mangled enough that it can use the _existing_ gamut of /etc/foo.conf files and their formats as the repository, rather than getting the immediate bennefit of a grand unified format. For that much of the process, libconfig is likely to be a read-only API in most cases, with man/vi still the preferred write API. At the very worst, it would consist of grabbing the existing config-file reading code from each application in turn, and whacking it so that the parsed results conform to the uniform in-memory structure, which the application is taught to use. Some time later, or even in parallel, the alternate libconfig(s) can be designed and tested, so that a pam-style switch is what is necessary to decide which config engine to use on a particular machine. As more write-friendly config storage formats are developed, the libconfig API can be extend to include the write access mechanisms required by configurators. These would just be ENOTIMP stubs in the "compatability" libconfig.so. One step at a time is the strategy. The trick seems to be finding small enough steps, and pointing them in the right direction. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010327081943.EE95A37B718>