[Rock-dev] Apropos base/orogen/interfaces
Jakob Schwendner
jakob.schwendner at dfki.de
Tue May 14 08:49:25 CEST 2013
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.
More information about the Rock-dev
mailing list