From owner-freebsd-arch Tue Mar 27 9:55: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lindy.rusher.com (adsl-64-164-192-197.dsl.snfc21.pacbell.net [64.164.192.197]) by hub.freebsd.org (Postfix) with ESMTP id 6DBD037B719 for ; Tue, 27 Mar 2001 09:55:01 -0800 (PST) (envelope-from jar@integratus.com) Received: from integratus.com (localhost [127.0.0.1]) by lindy.rusher.com (8.11.3/8.11.1) with ESMTP id f2RHvxZ03254; Tue, 27 Mar 2001 09:57:59 -0800 (PST) (envelope-from jar@integratus.com) Message-ID: <3AC0D4A7.CF09E4A3@integratus.com> Date: Tue, 27 Mar 2001 09:57:59 -0800 From: Jack Rusher Organization: http://www.integratus.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-arch@FreeBSD.ORG" Subject: Re: configuration files, XML? References: <200103270707.f2R77SR08693@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > around the bush. What specifically are you proposing? What would This is a mass reply. I will now address the following: o What's the problem? Unix file formats have traditionally been created in an ad hoc fashion in whatever format the author of that subsystem felt like. This leads to a seemingly random collection of position dependent, tagged, and line oriented file formats. The authors of the subsystems in question were likely to repeat the same set of parser errors with every subsystem. Steve Johnson's lex & yacc have made common input handling mistakes less frequent, but not everyone uses that technology. And, even if they DO use lex/yacc, it's so flexible that configuration file formats still remain random. Unix file formats don't contain self descriptive metadata (some people say "holographic labels"). This context information is really helpful in preventing people from making silly mistakes whilst editing these files. There is no constraint language for most configuration files. This makes it hard to write programs that can edit these files. You would essentially need to write one custom program for each format to make this work. This sucks for several reasons: sysinstall is harder to write & maintain, a "system configurator" is a big pain in the ass, and writing a netconfigd that allows machines to be reconfigured from the network is an artificially harder problem. There are more, but that seems like enough. o How does this relate to AIX? The point of this little project isn't to produce IBM's SMIT for BSD. Someone can write a SMIT if they feel that it'll make the end user experience more pleasant. The real point is that you've got a platform on which to write such a beast, or anything else that programmatically mucks with system configuration. I'm sure Son of Sysinstall would like this functionality. o What do you want to do about it? What I would like to see is a set of constraint files that describe the syntax of configuration files on the system, a consistent "style" for these file formats, and an API to access a library that knows how to deal with the underlying files. I would suggest that the library support loadable file format modules and that a hacked up constraint language that's able to express current file formats is the first module we write. After we have that much done, some enterprising soul could go around and retrofit this configuration file library into existing applications and subsystems. Note: at this point no user has experienced a user interface change. After we have all of this done, new applications and subsystems can code to the new API and avoid the common mistakes mentioned above & we can start experimenting with different back ends (XML, whatever) using an /etc/conf.conf approach. If we pull off the library correctly, we get conversion betwixt file formats pretty cheaply. Thanks, -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message