Re: [Core] Components design

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.

I think we must be very clear on the vocabulary we use: I'm not sure to
use all the subtelties of the english vocabluary very well...
I thought that "spec" would mean : "describe the complete behavior of a
module, including its interface to the outside world as well as it's
internal behavior".

But I'm sure things will get clearer in the future!


| able to identify themselves and their configuration (in order to allow
| dynamic (re)configuration), and their internal state (for monitoring
| and diagnosis purposes). 

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

| The
| latter seems to contradict the requirement for "encapsulation" via
| only the specification,

I don't think so! (I hope the working document i'll setup will enligthen
this aspect).


| 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". 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).

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


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

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

| In other words, we will implement some "architectures in the small",
| but no "architectures in the large".

I think we agree very well on that :)