Date: Tue, 27 Mar 2001 13:06:14 -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: <NCBBLOALCKKINBNNEDDLGEDODNAA.jonathan@graehl.org> In-Reply-To: <200103272014.NAA14374@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry said: > A real problem with XML is that there is very little in the > way of schema standardization out there (the one big exception > is EDI of financial data, which was standardized almost the > day XML came out). This is not a problem with the XML spec; what would you change about it that would solve this problem? I believe, for example, that standardization of XML DTDs for product descriptions of components (chips, fasteners, etc.) has been moving forward. > There's also the problem of divorcing object data from any > standardized accessor/mutator functions, which pretty much > damages any reasonable ability to do generalized triggers to > do things like regenerate sendmail.cf files when configuration > data is changed in the configuration base. It's somewhat of > a nasty problem, if you want to do this a minimal number of > times, given a large number of changes whose groupings are > designed by a UI person's idea of what's "logical", rather > than the data entry screens being in third normal form. I don't see why the DTD couldn't allow specification of actions to perform when modifying document subtrees. 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. > For that reason, it's generally much more useful to have a > protocol gating access to your data model, rather than just a > raw data model sitting around somewhere, with no way to demark > transactions into "do these changes atomically, and generate > the new sendmail.cf file only once, please". Suggestions? I agree that a uniform protocol for making configuration changes active is as important as a uniform format for describing them (although the action to make the changes active could itself be described in the schema). I would think the editor would signal the running daemon to reconfigure itself from the source data, after initiating any post-modification steps indicated in the XML configuration file. > What this basically means is that it's great, if you are doing > code that you don't expect to interoperate with anyone elses > code, and less great otherwise. XML gives you a data interchange format, not an actual protocol. Shared XML schemas can be extended while still allowing for base interoperability. > The primary reason I see it being used in places like IBM is > that it can tunnel RPC calls and other data over HTTP, which > people tend to let through firewalls. In other words, it is > capable of routing around anal retentive security types, who > live in deathly fear of FTP and DNS. IMO, XML was practically > invented just to get around IBM network security. I don't understand: why is XML necessary to tunnel your application-specific messages over HTTP? If I wanted to bypass IBM network security for my application, I could roll my own data interchange format that happens to look like HTTP requests/replies involving the usual port. XML-RPC-HTTP facilities may have been designed to bypass crude network filtering, but XML was not. > > Terry Lambert > terry@lambert.org > -- 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?NCBBLOALCKKINBNNEDDLGEDODNAA.jonathan>