[Rock-dev] Apropos base/orogen/interfaces

[Jakob Schwendner]

On 05/13/2013 05:17 PM, Sylvain Joyeux wrote:
> I have a strong feeling against base/orogen/interfaces. This is actually
> why it is still stuck on master, as
>
> My problem is that:
>   - the properties that are defined in the interfaces make only sense on
> one or two devices. They are not generic, and therefore the 'interface'
> is actually half broken (setting a property on task X is not guaranteed
> to actually produce something). This is already a problem we have with
> the camera interface.
>   - the value in having a common base class just to define one or two
> ports is IMO very limited
>
> So ... I'd like to hear the other side of the story ;-)
>
The rational for the interfaces was to have a way of making sure that 
devices of the same kind use the same types to transport their data, and 
also use the same name for the ports. We've discussed this with a few 
people from the rock-dev (you weren't there) a while ago. The reason was 
that I wanted to implement tasks that simulate a specific device. I 
think we had a few options on the table for this. One of them using 
interfaces through the inheritance mechanism of orogen. I seem to 
remember that we opted for this because it was implemented. I can't 
remember the alternatives, but I think they involved more work. I 
personally don't have a strong oppinion for or against the interfaces. I 
just looked at the code, and I am note sure I can share your observation 
that the interfaces are broken at this point. Yes, the Servo interface 
is not really an interface, but actually contains the sweep 
functionality. And yes again, the LaserScanner has some properties that 
may not be implemented for some devices. One easy way to fix this, is to 
move it out of the interface and into the actual device. Then we could 
say only things that have to be implemented by all the derived devices 
go into the interface.
I guess from a syskit perspective interfaces may not be so important 
since you do the modelling of the functionality on a different level. 
For the scripts I think they make life a little easier since the 
simulated and real devices really have the same signature.