Date: Wed, 12 Feb 2003 12:38:20 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: Wes Peters <wes@softweyr.com>, arch@FreeBSD.ORG Subject: Re: syslog.conf syntax change (multiple program/host specifications) Message-ID: <200302122038.PAA00115@thunderer.cnchost.com> In-Reply-To: Your message of "Wed, 12 Feb 2003 11:15:39 EST." <200302121615.h1CGFdGG025691@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> eschew is a proliferation of lots of little languages, each one subtly > different, such that users are forced to learn all of them. We > already have: [list deleted] > Every single one of these has a different syntax that the admin must > learn in addition to the relevant semantics, and which any sort of > front-end or configuration-analysis tool must be able to interpret, in > order to do anything useful with the programs they control. The > benefit of something like XML (or Lisp, for that matter) is that, You have my vote for a Lisp syntax (s-experessions). S-exprs are quite readable and lightweight -- you can't go lighter than s-exprs and still have a universal structured data representation. And you can parse them with a couple of hundered lines of C code (without having to worry about any buffer overflows or limits except the system imposed ones). > Yes, XML syntax is pretty hateful -- but because it is lexically > regular, my editor can do much of the work for me. It can do even > more of the work when the XML is coupled with a DTD so that it > understands more of the structure. In my view XML is to data representation what Roman numerals are to math. You _can_ do math in Roman numerals but people didn't do much for many centuries. The "syntax" must have overwhelmed them:-) A notation should encourage, not stifle, expression of ideas. At any rate XML is just another data representation language de jour. Likely, it will replaced by another one (and another) and all the lemmings will go over _that_ cliff. s-exprs been around for over 40 years without "evolving" significantly. Rather than repeat all the arguments I'll point you to what knowledgeable people like Erik Naggum have to say about XML (search comp.lang.lisp on groups.google.com). Naggum used to be a strong proponent of SGML until he "saw the light"! A couple of recent thread on XML on comp.lang.lisp are worth browsing. Another view is to not get tied too closely to the actual representation but standardize on a procedural interface. Then one can choose different representations depending on the context (e.g. when you have 10 accounts, use of a btree database for /etc/passwd is foolish; when you have 10000 accounts, use of a linear list is foolish -- but client programs of /etc/passwd should *not* need to be recompiled if the representation is changed). Yet another but related view is to extend the known interface of files and directories to configuration as they are the only truly first class objects in unix (in terms of programs that understand them). Pretty much every config file you mentioned but particularly files with simple and nested parameters naturally fit this paradigm. For instance, /etc/rc.conf would be a directory, files within it name specified parameters and their contents if any are their values. It is natural to "union mount" /etc/defaults/rc.conf _under_ it. Similarly, a kernel config can be a directory. Subsystems can be subdirectories and so on. Specific derived kernel confs can be union mounted on atop of that. But I guess that way lies plan9. -- bakul PS: The following Alan Perlis epigrams seem apropos. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. Simplicity does not precede complexity, but follows it. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process. 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?200302122038.PAA00115>