Re: [Core] Components design

Herman Bruyninckx wrote :
| [...] 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.

Thanks, this will help a lot!


| [...] 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.

Oh yes. One can very well imagine a list of "authorized users" associated
with services of modules. I also think this is not a critical issue at
the moment, but it's good to keep it in mind :)


| I thought about more than just parameters (this is "normal" use of the
| modules):

ok

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

Sure!

Your remark make me think of this:

There can be *several* modules providing basically the *same*
functionality to the rest of the "system" ("system" should be in the
glossary ;). For instance, I want to be able to run several localization
algorithms at the same time.

I think this is not a problem within the orocos context (since we do not
address the whole architecture problem), but as for other things, I think
we should keep that in mind.


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

Yes! What is important there is "same structure" but "different
mechanisms" (should I say "pattern" here?).

An implication of this is that the algorithms encapsulated by the modules
should *not* make *any* assumptions on what is the underlying system. 
This probably means that functional libraries should be built as a set of
functions that will just work on the data without taking care of
recieving or sending them (the latter beeing handled by the system).