Re: More on meta-ness (long)

[See note in last message.]

On 19/3/2002 10:44, Will Partain wrote:

> Could that be changed to (I don't know) host=.:ALL, simply because
> <team>:<thing> has been a "long" way to name a thing for a while...?

Yeah, sorry about that Will. I wasn't sure how to specify it sensibly. I'm
coming round to the idea of having:

    <code once-per-host=".:ALL"> ... </code>

instead, where this isn't special host magic but simply an instance of a
'once-per-<type>' pattern. I'd probably also allow the '.:' to be omitted.
I'm not sure if this should be allowed to be a list of thing names with
template expansion, so you could specify:

    <code once-per-host="@team:hosts-supported@"> ... </code>

This is still bouncing around inside my head though. Similarly I'd have:

    proxy-host="."

This means find a host object with that name and ask it to execute this
field for all the 'once-per' objects. The '.' name would be a special
request to ask the host meta-thing for a suitable "default" host. In the
case of hosts, this is the prompt-host (which neatly solves another horror I
was having). In the case of other thing types it would either be an error or
something sensible in that context. Also:

    proxy-host-table="build-hosts"

which means lookup the named table field in the current object and from that
get a mapping from 'once-per' thing names (or prototypes) to host thing
names (or prototypes? - what does that mean?).

> Tying in with what Jonathan's been saying: what's so special
> about hosts for making something right "for a whole site"?
> If I have hosts, users, websites, and routers as "things",
> should the semantics not be "execute the code across as many
> hosts, users, websites and routers as required to make 'foo'
> true for the whole site"?
> 
> Put slightly more formally, if I have things of type A, B,
> C, ..., Z, and 'foo' is a field in a type A thing, then
> forall B, C, ... Z, (note other A's omitted) make sure that
> 'foo' is true.  (Waves hands furiously...)

I've revised my view on this now. Having thought about it a bit more I've
decided the problem is not so much that hosts are special but that code is
special. Code is special because it has to be done "somewhere". In the
current Arusha it's assumed that code is always executed by host things.
I've been trying to abstract that so that you specify "what" should execute
the code explicitly or otherwise leave it to the meta-thing for the current
thing to do something sensible.

> [...] we still have at least one major horribleness,
> which we currently have with non-code-valued things:
> 
>  <foo>
>  <constraint><host-spec> hostA </host-spec></constraint>
>  <string>I am String A</string>
>  </foo>
> 
>  <foo>
>  <constraint><host-spec> hostB </host-spec></constraint>
>  <string>I am String A</string>
>  </foo>
> 
> At present, if you write thing.foo(), it's pretty random
> which value you'll get.  I wish we could define this problem
> away.

The constraints stuff is still causing me philosophical issues. At present I
have three things "in play" when executing code:

    the field thing
    the once-per thing(s)
    the proxy thing

which may all be different thing types, or may not. They may all be the same
thing actually. At the moment when I finally get around to asking something
to execute the field, I pass these in as context.

The latter two I think I can map to constraints OK. When you ask for a field
value with multiple choices, and there isn't enough context to determine the
right answer, I think the engine should raise an error. But I'm still a
little woolly on this.

I haven't implemented any of the constraint/dependency stuff yet so my
opinions on it may change.

Jonathan

-- 
jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd
http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451