[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Admin tools - idea from left field



On Thu, February 11 1999, Jules Bean <jmlb2@hermes.cam.ac.uk> wrote:
|On Wed, 10 Feb 1999, David Welton wrote:
|> I don't know XML and associated concepts real well - I'm a bit dubious
|> though - can you do anything besides create data formats?  (Please
|> respond in concrete terms - I can't stand all the hype-ish "enabling
|> system for the meta parsing of object oriented data storage and
|> knowledge enhanced blah blah" :-)
|
|All you can really do is define data structures, yes.
|
|OTOH, a program is only data. So, you could define XML for IF like this:
|
|<IF COND="$fred">
| ...
|</IF>
|
|And looping, etc.  Cold Fusion (spit!) does this.  It's pretty awful.
|Don't go down that road :-)

(This message is addressed to the list and not just to Jules)

True (about "Don't go down that road").  But is procedural programming
THAT crucial?  Compare this to the possible benefits of using a
standard, well accepted meta-data format like XML.  See how well most
of the programs manage without the procedural capabilities - just look
at your /etc directory.

I was thinking of this (common configuration format for all
applications) too.  XML have the advantage that you can start by
defining DTD's to replace most current text files used in UNIX
(anything under /etc, basically, starting with /etc/passwd and ending
in cvs.conf) and translate these to the old format as a transitional
phase. That way you get both the "common format" many of us would love
to see (so it seems from the responses so far) while still being able
to use unchanged upstream code.  The next stage might be to embed the
XML parser (or whatever final format you decide to go with) right into
the upstream source.  XML is already supported by many languages
(Perl, Python, Java, C, C++ if I remember right) and extensible (well,
that's what the "X" stands for :).

One huge advantage of XML is that it is expected to draw lots of code
to manipulate it.  See, for instance, what hacks are required to let
PostScript tools "manipulate" PS files via conventional remarks.

Take for instance /etc/cvs.conf, it looks like a shell-script which
I'd expect the reading script to simply "source" (I'm guessing here,
but just for the sake of the argument).  Have you ever taken advantage
of the fact that it is a script?  It's true that maybe someone might
need that, so my tentative answer to that is that XML might be able to
enable this while still letting most people have a nice toggle
"yes"/"no" button to set CVS_ROTATE in an XML file (and then translate
it to cvs.conf in its current format).  If someone wishes to insert a
shell stanza then he might either embed it in the XML file or bypass
the entire system XML.

Another example of something which might be analogous - look at
Sendmail's config - it used to be hairy (and still is), but it now
uses a pretty convenient .m4 scripts to do most of the work without
loosing the power of the lower level config (NO!  I'm not advocating
use of .m4, I think XML is better for this task and much more
standard).  (Thinking of this - M4 allows control-follow to, right?
Have you ever took advantage of this?)

Another "use-case": how would a scripting language like
Python/Perl/Guile/whatever benefit the kernel's "config"?  It's true
that it is possible (and even easy) to do that with a scripting
language, but at the same time you can get XML to define all possible
options (I think you can also define dependencies and get a generic
XML editor to relate to them) as well as a particular configuration,
and take advantage of XML parsers/editors to config the kernel.

It sounds like the Casbah project are thinking (pipe-dreaming? :) of
this too, BTW.

As an example (speaking of a blind leading the blind.  I haven't got
around to read a decent XML book yet), here is what a replacement
lilo.conf.xml might look like:

<DTD...>
<lilo-config>
  <boot>/dev/sda1</boot>
  <root>/dev/sda1</root>
  <compact/>
  <install>/boot/boot.b</install>
  <map>/boot/map</map>
  <vga>normal</vga>
  <delay>20</delay>

  <image name="/vmlinux">
    <label>Linux</label>
    <alias>0</alias>
    <read-only/>
  </image>

  <other name="/dev/sda3">
    <table>/dev/sda</table>
    <label>Lose95</label>
    <alias>9</alias>
  </other>
</lilo-config>

That's basically it.  A DTD shall define what sort of values are
allowed for each possible field, a bit reminiscent of a combination of
Yacc and Lex.

I don't know if I managed to convince you (I'm a bit hazy about XML
myself), but please try to consider these points as you continue to
investigate this important subject.

Cheers,

--Amos

--Amos Shapira                    | "Of course Australia was marked for
133 Shlomo Ben-Yosef st.          |  glory, for its people had been chosen
Jerusalem 93 805                  |  by the finest judges in England."
ISRAEL        amos@gezernet.co.il |                     -- Anonymous


Reply to: