[RTT 2.0] Provides vs. requires interfaces

Hi,

[disclaimer]
I think the following entry expresses an example of a problem caused
by the fact that one cannot express required and provided interfaces
in RTT 1.x, and as such is described at
<http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces>
I might have completely misunderstood the entry though
[/disclaimer]

I've just seen an orocos application which looks approximately (simplified) as

TaskContext UserInterface (UI)
TaskContext DoSomething (DS)

The functionality of DS is (partly) described as a (scripting) FSM, of
which a relevant part looks like

state waitingState
	{
		transition UI.startTest()
		{
			/do st
		} select otherState

which revealed a "bah, that's ugly" scream from my side. Why ugly, you wonder?
Well, since the implementation of the FSM has a _hard_ (I know, it
ain't compile time, but still) dependency on a component named UI.
Which means that if I replace UI with GUI, I have to rewrite my
component's FSM. Indeed, in this case DS has a hard dependency on UI.
Which is not my understanding of component based design.
The solution?
As a "workaround", one can add an event "startTest()" to DS, and react
to that event in the transition statement. However, this only
reverses/alleviates the problem, since now UI has a hard dependency on
the existence of DS (UI has to know it is talking to DS). Now, for
sure this ain't so bad as the original code (it is more likely that UI
changes then DS), but I still dislike the hard dependency. And in
this case, UI is not a nicely decoupled component.

So, what I would _really_ like as a solution for this one, is that UI
can specify that it requires an interface of type StartTestInterface,
and that this condition is checked when the components are connected
to each other.

So now the questions:
- Is this example indeed something which is meant by the wiki entry
mentioned on the top of this post?
- If so, should I add this example to the wiki?
- Is this still/really on the 2.0 todo list?
- Are there other solutions for this "issue" in RTT 1.0?

TIA,

Klaas

[RTT 2.0] Provides vs. requires interfaces

On Mon, Jun 22, 2009 at 14:19, Klaas Gadeyne<klaas [dot] gadeyne [..] ...> wrote:
> Hi,
>
> [disclaimer]
> I think the following entry expresses an example of a problem caused
> by the fact that one cannot express required and provided interfaces
> in RTT 1.x, and as such is described at
> <http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces>
> I might have completely misunderstood the entry though
> [/disclaimer]
>
> I've just seen an orocos application which looks approximately (simplified) as
>
> TaskContext UserInterface (UI)
> TaskContext DoSomething (DS)
>
> The functionality of DS is (partly) described as a (scripting) FSM, of
> which a relevant part looks like
>
>

> state waitingState
>        {
>                transition UI.startTest()
>                {
>                        /do st
>                } select otherState
> 

>
> which revealed a "bah, that's ugly" scream from my side.  Why ugly, you wonder?
> Well, since the implementation of the FSM has a _hard_ (I know, it
> ain't compile time, but still) dependency on a component named UI.
> Which means that if I replace UI with GUI, I have to rewrite my
> component's FSM.  Indeed, in this case DS has a hard dependency on UI.
>  Which is not my understanding of component based design.
> The solution?
> As a "workaround", one can add an event "startTest()" to DS, and react
> to that event in the transition statement.  However, this only
> reverses/alleviates the problem, since now UI has a hard dependency on
> the existence of DS (UI has to know it is talking to DS).  Now, for
> sure this ain't so bad as the original code (it is more likely that UI
> changes then DS), but I still dislike the hard dependency.  And in
> this case, UI is not a nicely decoupled component.
>
> So, what I would _really_ like as a solution for this one, is that UI
> can specify that it requires an interface of type StartTestInterface,
> and that this condition is checked when the components are connected
> to each other.
>
> So now the questions:
> - Is this example indeed something which is meant by the wiki entry
> mentioned on the top of this post?

Yes.

> - If so, should I add this example to the wiki?

Good as a motivational example.

> - Is this still/really on the 2.0 todo list?

Absolutely. See the wiki pages below
http://www.orocos.org/wiki/rtt/rtt-20/contribute-suggest-new-feature-be-...

It's on the map.

> - Are there other solutions for this "issue" in RTT 1.0?

The current work around is to use 'aliases', but the deployer does not
support them. You can add a peer under a different name during
'addPeer'.
It's not *such* a big issue afterall since you can freely choose the
names during deploy time. It's a 'name', not a 'type', but your
scripts must indeed all agree on the same name.

Peter