Will Partain | 16 Jul 21:17 2002
Picon
Picon

updates 2002.07.16

Folks, I should probably send out some kind of ARK status
update, but... meanwhile, I just checked in the usual pile
of stuff.

ARK engine -- essentially no changes.  Documentation --
ditto.  So nearly everything is Sidai stuff for packages
that I've been playing with, including: exmh, expect,
metamail.xml, php, squirrelmail, ghostscript and gv, and
nmh.  (Sidai now has "smarts" -- well, some of it is
probably still "dumbs"... -- for over 200 packages.)

Please check the ark-commits mailing-list archives (or just
ask here) if you want more details.

Will

PS: Status summary: quiet and low-key, but still looking good.

-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim
Jonathan Hogg | 29 Jul 10:35 2002

SA-ML anyone? (oh so very long)


[Warning: another of my long rambling essays follows.]

--- XML: not just a verbose data format! ---

I've been doing a bunch of stuff with XML recently and learning a lot more
about XSLT/XPath/namespaces/etc. than I knew before. I've been wondering if
we could use XML for more than just a conveniently parsed config format.

You may have read already my murmurings on making Arusha more regular and
extensible. I was focusing before on metathings and the Python object model
side of things, but I've been thinking more recently that perhaps we should
look more closely at the configuration files themselves.

I've been inspired by XSLT (which, I've been delighted to learn Will, is
just a functional language!) to rethink Arusha and the idea of documenting/
automating sysadmin practice.

Consider for a moment, a basic GNU-style package spec:

  <package name="python--2.2.1" xml-version="1">

  <status>revealed</status>

  <prototypes>
    <prototype team="." name="GNU"/>
    <prototype team="." name="ALL"/>
  </prototypes>

  <assemble-source>
(Continue reading)

Will Partain | 29 Jul 17:49 2002
Picon
Picon

Re: SA-ML anyone? (oh so very long)

Jonathan, thanks for a super-interesting read; I'm not yet
in a position to comment sensibly (and am off on holiday in
a week's time...), but thought I would go ahead and toss in
a few mumblings of my own.

> So having argued in the past for rationalising and extending the Arusha
> object model, I'm now arguing for throwing it away entirely ;-)

For my part, I've been more inclined to keep the object
model and ditch all the XML-ism :-)

Some concerns with your XSLT (courtesy of Phil Wadler,
surprise) line are:

(a) Grokkability by Real Sysadmins (TM) -- I have a constant
worry about "this stuff is too hairy, and no-one will touch
it" re ARK things.  I am pleased with the (relative)
simplicity of the present ARK stuff, but it is far from
clear if that's good enough.  XSLT might push us way over
the edge.

(b) Doing better with "constraints" (as we now call them)
[or dependencies]:  My hunch has been that if ARK <n+1> is
going to be qualitatively better than now, it will be
because of a better story on constraints.  Would XSchema/etc
stuff make it easier to get that "better story"?

(c) The CERN people have done a configuration language with
type checking (PAN; they have a LISA paper on it this
year).  We could always go wild and show them how it's done
(Continue reading)

Jonathan Hogg | 30 Jul 11:35 2002

Re: SA-ML anyone?

On 29/7/2002 16:49, Will Partain wrote:

> For my part, I've been more inclined to keep the object
> model and ditch all the XML-ism :-)

Heh, I must have been reading your mind and decided to go the other way out
of contrariness ;-)

> Some concerns with your XSLT (courtesy of Phil Wadler,
> surprise) line are:

[Heck, what's he up to these days?]

> (a) Grokkability by Real Sysadmins (TM) [...]

Grokkability is probably my prime concern about Arusha at the moment. I'm
worried that understanding what's happening in sidai requires taking apart a
whole heap of inter-dependant config files and sections of the core engine.

My related concern is that we've tangled up the information with the
mechanism. There's a very blurry line between "how is PHP configured at this
site" and "how did we configure PHP at this site". They seem almost the
same, and Arusha/sidai tends to treat them the same, but I'd like to be able
to view them differently.

To explain what I mean by this, consider the whole 'configure_args',
'extra_configure_args', 'ldflags', 'dep_lflags', 'proxy-host:LDFLAGS', etc.
madness. I've tripped over this a few times in the last couple of days
trying to get (surprise) PHP+extensions configured. I didn't sufficiently
understand how all these relate to each other and managed to disable
(Continue reading)

Will Partain | 30 Jul 15:04 2002
Picon
Picon

Re: SA-ML anyone?

> [Heck, what's [Phil Wadler] up to these days?]

Well into things XML; see http://www.research.avayalabs.com/user/wadler/

> Grokkability is probably my prime concern about Arusha at
> the moment. ...

We're OK, then :-)

> To explain what I mean by this, consider the whole 'configure_args',
> 'extra_configure_args', 'ldflags', 'dep_lflags', 'proxy-host:LDFLAGS', etc.
> madness. I've tripped over this a few times in the last couple of days
> trying to get (surprise) PHP+extensions configured. I didn't sufficiently
> understand how all these relate to each other and managed to disable
> important behaviour and mess up the first few builds.

Two things: (a) The PHP stuff in Sidai is far from ready for
prime time [as you've discovered]; I would hope it would
grow to be decent.  (b) There are a set of ill-documented
*conventions* that have grown up around those Sidai params;
e.g. "configure_args" is used by the Sidai prototype, but
"extra_configure_args" is used by the local team.
Conventions are a cheap way to get lots of power; e.g. the
original unix "everything's a line-oriented text file"
convention.

> ... "add some more syntax". This is sort of based
> on the idea of Lisp macro programming, but using XSLT. ...

We're all feeling really comfortable right now... :-)
(Continue reading)


Gmane