Peter,

I have been thinking how the subsumption architecture is going to be
implemented and wondered what you originally had in mind. Here are some
of my thoughts:

Each AFSM and each connecting node (inhibit, default, etc) in the
network is a seperate unix process.
 - this is easy to do and a realistic simulation of what would be going
   on in one of brooks robots
 - but there will be loads of processes, this may be inefficient? John
   Hallam came across a problem with many connected unix processes that
   involved a block of X seconds every Y seconds

The nodes need not be seperate processes but could be modelled at the
receiving AFSM. For example each AFSM is a unix process with a
subprocess which is allocated a bit of time within the main process.
The subprocess gets incoming data applies a series of 'node operations'
then writes it over the old data, ready for use by the AFSM.
'node operations' are the I,D and S nodes of brooks.

 - this may not be able to model complex networks - maybe
 - it retains some similarity to a real network

The nodes and all connections could be handled by a single process which
is connected to all AFSM's. No two AFSM's are connected directly.
 - this is not like a real network but may have the same effect
 - it may be messy and problematic to program?, with side effects that
   would not occur in a real network?

Several AFSM's could run in one unix process, each having a slice of
the time. Just a few of these processes are connected. The user
specifies which AFSM's are to be connected but the program decides
wether the link is to be inter- or intra-process.
 - messy/difficult ?

I would appreciate your thoughts on this stuff,
 thanks,

Ian

-----------------------------------------------------------------------------

> The nodes need not be seperate processes but could be modelled at the
> receiving AFSM. For example each AFSM is a unix process with a
> subprocess which is allocated a bit of time within the main process.
> The subprocess gets incoming data applies a series of 'node
operations'
> then writes it over the old data, ready for use by the AFSM.
> 'node operations' are the I,D and S nodes of brooks.
>
>  - this may not be able to model complex networks - maybe
>  - it retains some similarity to a real network

This seems to me to be the `natural' sensible answer; either this
or a variant in which each AFSM is a separate process, and each "node
cluster" (ie pick a node, search out as far as you can till you hit
AFSMs, maximal subgraph is one cluster) is an instance of a process
which does the necessary `node operations'. A bit of thought about
how the user may want to interact with it all should help to make
the decision.

Obviously the processes which implement the nodes cannot die without
major effects. I guess it might be possible to have one single process
responsible for all routing and all nodes - a kind of `breadboard'
process, as it were. Again, an object-oriented approach suggests itself,
containing node instances each of which knows where input is to come
from (other node or AFSM-link object) and where it is to go to (other
nodes and/or AFSM-links).

Peter

