Meta-things

Hi all,

I've been wandering over the Arusha code-landscape over the last few days
and something is unsettling me. So I thought I'd bash it out in a post and
see if it generated any interesting ideas.

Intertwined throughout the arkbase is the notion that all things are not
created equal. Different things need different handling. A few of the main
cases that spring to mind are:

 * Code setup: special magic is invoked to setup code and param templates
   if the thing is a package.

 * Run host: as evidenced in my hacking this weekend, the machinery that
   determines where to run a piece of code is thing-type dependant.

 * Relevancy: determining what things are relevant varies on type.

 * <thing>.py: on an obvious note, all the code in <thing>.py is clearly
   thing-type dependant.

 * #ark-site: the code is littered with these magic tokens that introduce
   places where site-specific thing-type dependant code can be inserted
   at bootstrap time.

I'm aware that all this magic Gets The Job Done, but from the Thousand Foot
View something makes me uneasy about this ad-hocery.

I've recently been playing with Python 2.2 and observing Guido's efforts to
rationalise the type-class machinery in Python making it more consistent and
at the same time exposing more of it to the advanced hacker. The whole
meta-class stuff made me think of the idea of "meta-things" in Arusha.

My Big Idea is to ditch the current <thing>.py modules and move all
thing-type dependant code into <thing>.xml files. These would exist in the
team directories as per current things, but under a 'thing' subdirectory. At
ark startup, these would be "sourced" into the Arusha interpreter building
the meta-things that are used to construct things.

Too many things in that sentence. Perhaps an example:

    <thing name="host">

        <is-relevant><code>
            return self.status() == 'active'
        </code></is-relevant>

        <code-host><code>
            if once_per == 'host' and proxy_hosts = None:
                host = self
            elif once_per == 'site':
                [...]
        </code></code-host>

        <code-setup><code>
            params['hostname'] = self._name
        </code></code-setup>

    </thing>

The code fields here are slightly different to standard ones in that they
are Python only and are executed at the appropriate places in the engine.
Effectively these are used to fill in methods of the 'Ark<thing>' classes.

The <thing>.xml files would also be used to build the thing modules. So on
hitting a 'website.xml' file, the engine would make a 'ark.website' module
and populate it with a standard 'ArkWebsitesMgr' singleton and a newly
created 'ArkWebsite' class. Thus the core ark engine would be reduced to
just the thing machinery.

Why bother?, isn't this just moving the same code from one place to another?

Yes. And no. To keep things simple I envisage that the ARK team wouldn't
contain any of these <thing>.xml files. All the current code would be moved
into the sidai team. For a sidai-style site, one would populate the thing
directory with empty 'host.xml' and 'package.xml' files that reference, via
the standard prototype magic, the sidai ones. This means that if at my site
I disagree with the way that host <code-setup> is done by the sidai team, I
can just override that field in my 'host.xml' file. I can also trivially add
new thing-types.

Erk. This sounds complicated as all hell Jonathan! Are you volunteering?

I'm sort of hoping that, while it might look complicated, it'd actually
simplify some stuff. As to volunteering, I think I'll hold off until I've
had some feedback and have thought about it some more myself. I may try
playing with a prototype to demonstrate my ideas (to myself as much as to
anyone else!).

Begin comment.

:-j

-- 
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