Re: [COMPONENTS] Gnome's OAF allows `Capability-based activation'...

| > ``A unit of composition with clearly specified interfaces and
| > functionality. It can depend on context, but this dependence is made
| > explicit. A software component is an independent unit, consisting of
| > different modules, should be reusable, exceeding the concept of
| > ``small'' entities such as classes, be able to interrogate other
| > components to find their interfaces (and be interroated itself), be
| > able to generate and handle events, and deliverable by third parties
| > on the basis of its interface specification only.''


Peter Soetens (Kaltan) wrote :
| What might be a bit strange is that you define a component as something 
| "independent" (from what ?) but you still state that a component can depend 
| on the context, under strict conditions.  

Yes, maybe the definition should precise "depend on context". I don't
clearly see what it means :) (what context, and what would be the
dependency ?).

Furthermore, what would be then the definition of a module?


| I have found another definition ( 
| http://www.dis.uu.se/~zeykiz/Papers/CBSEreport.pdf ) which is more
| elaborated and that paper also discusses other interesting definitions
| like 'framework',  'interface', 'patterns',... and the relation between
| them. 

Interesting!
In paticular : "a component cannot be distinguished from copies of their
own [...] there will be at most one instance of a particular component". 
If we reuse that part of the definition, we could understand a component
as a "set of modules" (one component for pose estimation, one for path
planning, etc..). I think there are pros and cons to that vision:

Pros:

We could exhibit a per-component "intelligent service server" (as I
mentioned it in a previous mail). This can handle wery well the problem
of "several module for one functionality".
BTW, I forgot to CC here my answer to Herman's question. Basically, I
just said "intelligent service servers" was an idea of mine (I'm not
aware of any implementation of this).

Cons:

I'm affraid we will rapidly end up with "one module per component",
except for a few particular cases. It will also be very difficult to
think of every possible component, or make people aware of existing
components to prevent them from reinventing their own one.

Opinions?


| > One of the important things is this "interrogateability", I think...
| 
| absolutely, I believe you mean the plug-and-play opportunities of 
| "interrogatebility"

"plug and play" is actually a difficult problem. Ideally, we'd like the
following scenario :
You write your module, put it into an existing component, and you would
like the system beeing able to use it right away without the need to
write anything more.

That's a very challenging objective, because the range of robotics
modules is wide, and we won't be able to identify every necessary part
in a glance (and you must do so if you want a true plug and play system,
because of the specific aspect of every parts).

I think a first objective is "interoperability". We should let
every user define how the modules he puts into its system are used, and
control what's happening. Bascially, we should let the user define the
data flow and the control flow. Of course, this must be done *outside*
the modules (to keep modules modular).

We can still aim at some automatisms, but I'm affraid that if we want to
do too much too rapidly, we will end up with some too much restrictive
(unusable?) system.
But I'm open to the discussion!