Date: Mon, 26 Mar 2001 18:14:43 +1000 From: "Andrew Reilly" <areilly@bigpond.net.au> To: Jack Rusher <jar@integratus.com> Cc: Jordan Hubbard <jkh@osd.bsdi.com>, jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML, Mac OS X release Message-ID: <20010326181443.A75840@gurney.reilly.home> In-Reply-To: <3ABEB519.CA9F1029@integratus.com>; from jar@integratus.com on Sun, Mar 25, 2001 at 07:18:49PM -0800 References: <NCBBLOALCKKINBNNEDDLMEBODNAA.jonathan@graehl.org> <20010325170513Z.jkh@osd.bsdi.com> <3ABEB519.CA9F1029@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 25, 2001 at 07:18:49PM -0800, Jack Rusher wrote: > Jordan Hubbard wrote: > > > > The project has a Mac (eatmorepie.freebsd.org) running the OS X > > release candidate, though it appears to be down at the moment (I'll > > fix that). Someone can certainly log into it at some point and > > look this stuff over. > > I took a look at the release during the big pre release party at > Apple. It looks like the only XML DTD they have in the system is a > property list DTD designed to allow them to store groups of key/value > pairs as the backing store for application configuration data. > > I remain willing to help integrate a lightweight BSD license XML based > configuration management system into FreeBSD. Does anybody really want > such a beast? I really like the idea of a uniform and configurator-friendly config management system. I'm not crazy about XML, but my opinion on the subject hardly matters. However, it occurred to me a while back that there is no need to do this all at once, and probably many good reasons not to. I'd suggest that an approach might be: 1) Dermine a C API for access to the (XML?) config files. 2) Build a library that implements that API. 3) Convert the ad-hoc config file mechanisms in each application to use the library as well or instead. It sounds as though you have (1) and (2) sorted out. (3) is the biggie, but as I mentioned above: it doesn't have to happen all at once. None of the existing applications share config formats, or rely on common mechanisms, so changing them one at a time will have the positive effect of allowing for the necessary user education process to be gradual. It also gives more room for gradual refinement of the API (1) to accommodate different functionality. Once there's a config API and implementation, it should be an easy (or easier) matter to replace or modify the library to include other forms of config store, such as LDAP databases or netinfo servers or whatever. Note too that (at least with a text (XML) style config store) all of this can be done without the pre-existence of a universal configurator tool, which history has shown to be a difficult and complicated beast. -- 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?20010326181443.A75840>