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... :-)

> > (b) Doing better with "constraints" [...]
> 
> I don't know. So far I'm pretty happy with constraints, so I'm not sure how
> to do better ;-) But then I have a relatively simple setup at the moment.
> What things are bugging you Will?

Being able to push a big button and have oodles of stuff
Just Happen (TM) relies on good constraints.  It's a really
hard thing to do well -- look how many people have taken a
shot at it :-)  Things that spring to mind:

* Being able to have constraints in your prototypes, e.g.

  <package name="rsync">
  <prototypes>
    <constraint><host-spec>sidai:solaris</host-spec></constraint>
    <prototype team="sidai" name="solaris-pkg">
  </prototypes>
  <prototypes>
    <constraint><host-spec>sidai:hpux</host-spec></constraint>
    <prototype team="sidai" name="hpux-pkg">
  </prototypes>
  <prototypes>
    <constraint><host-spec>sidai:linux-rh</host-spec></constraint>
    <prototype team="sidai" name="rpm-pkg">
  </prototypes>
  </package>

* Being able to "blow up" a Sidai constraint in a team file;
so if the Sidai package for apache says

  <constraint><dependency type="normal" name="openssl" on-method="deploy" /></constraint>

in my team file, I'd either like to say "no, *I* don't want
to depend on OpenSSL", or be able to say "yes, and what's
more I want to depend on *precisely* version 0.9.7-beta2".

* I _like_ the idea that a constraint simply means "you've
run method <x> of object <y>": elegant.  Most of the rest of
our constraints thing feels like a hack.

> > (d) There's another LISA paper about using the Zope-like
> > idea of "acquisition" in a configuration language [...]
> 
> Hmmm... is any of this getting closer to something that the average syadmin
> would use?

I think it's quite grokkable.  But I don't think it gives
any extra power, so I'm not sure you're that far ahead.

> But what if it could be? What if you could do something like:
> 
>   <section id="configure">
> 
>   We configure PHP with the <args>--enable-xslt</args> option
>   in order to get the XSLT extension. We use
>   <dependency id="sablotron--0.95">Sablotron</dependency> for
>   the actual XSLT engine, which requires adding the argument
>   <args>--with-xslt-sablot=<deploy-dir id="sablotron--0.95"/></args>.
>   We add the optional <args>--with-sablot-js</args> argument to get
>   the EXSLT JavaScript extensions.
> 
>   </section>

And what would the guy who comes along behind and says, "I
want to do the same PHP thing as that guy there, only with
the following differences..."?  That question is our reason
for existing, after all :-)

Will


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31