Date: Tue, 27 Mar 2001 17:29:50 -0800 From: "Jonathan Graehl" <jonathan@graehl.org> To: "Terry Lambert" <tlambert@primenet.com> Cc: "freebsd-Arch" <freebsd-arch@FreeBSD.ORG> Subject: RE: configuration files Message-ID: <NCBBLOALCKKINBNNEDDLCEEDDNAA.jonathan@graehl.org> In-Reply-To: <200103280049.RAA26184@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > If the XML file were > > the primary source of configuration information for my program, I > > would not want any accessor/mutator functions at all; I would > > simply provide validation constraints and construct what I need > > from the configuration file on startup, or when signaled. > > This gets back to the cached configuration data problem. For > the sendmail example, the host name might change, and sendmail > would not be aware of the change, and would therefore answer > connection requests with incorrect data. > > Similarly, the need to HUP a bind serving 10,000 domains takes > the bind out of service for the reload period (DNSUPDAT can help > this, but only if you hack bind to permit zone creation/deletion > via DNSUPDAT). > > The problem with this approach is that you are, in effect, making > your server unreliable, in exchange for making the changes take > effect more quickly. Excellent point - I did not consider the need to incrementally (atomically) update huge configuration stores while the server still acts on the old configuration. > It is simply not acceptable to have to take on the maintenance burden > of teching every open source package on the planet how to do its own > link management, without a centralized policy enforcement mechanism. I agree. Similarly, we can't expect every package to spontaneously come up with a common configuration file format ;) > By the same token, a centralize policy enforcement mechanism is > needed for UNIX configuration data as well. > > Vanilla XML, without a protocol, API, or other procedural access > point to provide subschema enforcement of your validation > constraints suffers many of the same weaknesses we fought.. I agree; vanilla XML simply replaces many arbitrary data formats with a single flexible format (with an explicit DTD). Having XML configuration files would be wonderful, but you are right, there are other problems to solve as well. > ACAP is one option. My personal preference would be LTAP, if the > LDAP server modifications for asynchronous notification could be > pried free from Lucent. LDAP would work, if a simple transaction > extension were added (nesting would not be required, if data were > properly normalized). The back end data store for the protocol > server could be XML (or ROT-13 binary files; it doesn't matter). First I've heard of the two ... http://asg.web.cmu.edu/acap/ ACAP RFC: ftp://ftp.isi.edu/in-notes/rfc2244.txt (looks like a nice idea; web page seems to be neglected) http://www-db.research.bell-labs.com/project/ltap/ (patent filed?) LTAP looks like a gateway to a backend that lacks triggers, where you access the backend through the gateway and you can request notifications when certain accesses are made by others? Do you like their protocol, or just the idea? > I have to say I'm violently opposed to signaling as a catch-all; > I understand that it's the standard means of informing a daemon > of a configuration change, but an overly simplistic, low granularity > approach is exactly what must be avoided. Well, like it or not, it is the easiest way to do things. A basic configuration file meta-format and signaling mechanism would still be good. I agree that more fine-grained stuff for updating in-use configuration data should be developed, and that such a beast might as well have nothing to do with XML (except that an XML language could describe the interfaces/data types :). In cases where static configuration files make sense, I would like those configuration files to be XML (or some other unified meta-format which can be programmatically operated on without case-specific coding). > > > XML gives you a data interchange format, not an actual protocol. Shared XML > > schemas can be extended while still allowing for base interoperability. > > I'm (I guess) known for the statement "standard plus extensions > is not standard". I think that deviations from standards render > code practically useless. The "extension" I was referring to was that of augmenting a DTD such that it still has enough in common with the "standard DTD" that programs will still be able to get the standard information out of your document. I was not referring to an extension to XML itself. A protocol for passing around bits of XML data is outside the scope of the XML standard itself. I didn't realize that people passed around XML documents without publicizing their DTDs. That sucks. I'm not sure a requirement to include the DTD to be "standards compliant" would prevent people from being proprietary if they still want to. -- Jonathan Graehl http://jonathan.graehl.org/ 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?NCBBLOALCKKINBNNEDDLCEEDDNAA.jonathan>