Re: About component architectures...

Herman Bruyninckx wrote :
| I am not too happy with a `supervisor' because that is such a general
| name that covers too many different things we want to separate.

I think what you really want is an "execution control layer", which can
be made of several components: 'configurator', 'resource management',
'consistency checks' (e.g. checking that you are not doing things with
the 'functional components' that are not allowed), 'communication
management' (e.g. some of the functionalities of an ORB), etc...

[ I use the term 'functional component' to talk about the components of
the functional layer ]

| - Configurator (what the people in LAAS call ``control flow'' I guess),

Not really: the control flow is much more general. With our terminology,
the control flow represents all the service requests that are made to the
'functional components'. 

| - Mediator (``data flow'') that accepts service requests from
|   the user and divides those into actions for its sub-components.

[ Services requests are part of the control flow ]

Your Mediator is what I called 'communication management' above. And it
must take care of both the data and the control flow.

A simple example to make things clearer:

Let's say you have a component A that can produce data (A.ouput) and a
component B that need data (B.input).

The control flow represents the floowing actions:
"tell A to start producing A.output"
"tell B to read B.input from A.output"
"tell B to start using B.input"

And the data flow would represent the link so established between A and
B.


|   A key property of a Mediator is that it intervenes in _every_
|   interaction between the objects or components it mediates. This seems
|   the case to me for all service requests that enter the component.

Yes :)

| Maybe it's even more, but I hope not, in order to keep things simple.
| 
| Should we make separate sub-component for each of these ``roles'' or
| should we do just that: call it supervisor, and give it different
| roles (Configurator, Mediator) to play?

No, I think it's a good idea to make separate sub-components :)

But I wouldn't call 'supervisor' the set of the sub-components you are
talking about. In the literature, the supervisor is the one that makes
decisions about the services to activate whithin the functional layer.
I think we are really talking about the 'execution control layer' of the
3 layered architectures.

| I hope (and am quite sure) to be able to use existing Software Pattern
| names as much as possible, because this helps a lot in documenting
| what we mean.

I only know about the 'autonomous robots' vocabulary :)
But it sure would be helpful to reuse standard names whenever possible!