Re: [Core] Components design

On Fri, 7 Sep 2001, Anthony Mallet wrote:

>
> Herman Bruyninckx wrote :
> | Next to this "specification" face of components, I think there is also a
> | "framework" aspect: components should have a prescribed set of
> | "meta/supervisor" functionalities:
>
> IMHO that's the primary goal of the module specification.
> So I completely agree on that.

Ok. But one thing has been made clear once again: we need to define
our terminology :-) I'll make a page for this purpose, and fill it
with the preliminary glossary of terms that I can come up with.

> Yes that's an important point. I think that can be provided by the
> standard "software pattern" of the modules.
> Btw, I'm not sure to understand well "software pattern". Do you think
> it's the same as a "canvas" ?

Yet another terminology problem :-) I use the term "software pattern"
as it is used in the books about this subject. I have the links on the
orocos web page.

> | but I tend to suggest that our components
> | should have two faces: one with their user functionality, another one
> | to allow the "supervisor" in the system to make the system dynamically
> | reconfigurable.
>
> Well, I think there must be no difference between a "human user" of a
> module and a "software user".

No, but maybe there is a difference between a normal user and an
authorized user (i.e., one that can change the configuration of the
whole system)?


> The only differences will be located
> at the other end of the "modules" (a user will have an interface to
> control things and a supervisor will run some code, but from the "module"
> point of view this should not make any difference).

Depends on whether we want to put an authentication server in the
system. I don't think we should go that way in the near future, but it
will definitely be an issue later on.

> Regarding "dynamic reconfiguration", if you're speaking of "parameters"
> for the algorithms I think they should be programable using "services"
> provided by the modules.

I thought about more than just parameters (this is "normal" use of the
modules): replacing one module by another one is a reconfiguration
feature that should not be done at the same level as the call of a
method on a module.

> | > This description [...] should also be generic
> | > enough to fit in the requirements of every module (ranging from
> | > rtlinux in-kernel tasks to any-time userland processes).
> |
> | I don't quite understand what you mean with this last sentence...
>
> Well I think we must describe the "requirements" of every
> module (time of execution, periodicity, real-time or any-time, bandwith
> required on input or ouput data, etc...).

Ok! These are constraints which would allow the "supervisor" user to
reconfigure dynamically; for example: the same module structure could
be used for soft real-time, but also for hard real-time, but in both
cases some of the IPC (for example) should be different.

> If we come up with several "systems", these systems should be
> able to find the necessery information to decide if they can handle a
> particular module or not. For instance, the current version of GenoM
> cannot handle timers below 5ms. If a module requires more precise
> control, GenoM should be able to say "I can't run that module".

Indeed. This is what I call "supervisor" mode. (Another thing we
should find a name for :-)

Herman