From owner-freebsd-arch Tue Mar 27 13: 6:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id D335B37B719 for ; Tue, 27 Mar 2001 13:06:48 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2RL6eE32280; Tue, 27 Mar 2001 13:06:40 -0800 From: "Jonathan Graehl" To: "Terry Lambert" Cc: "freebsd-Arch" Subject: RE: configuration files Date: Tue, 27 Mar 2001 13:06:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200103272014.NAA14374@usr05.primenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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