[Robotics] Integration of middlewares

[Paul Fitzpatrick]

Herman Bruyninckx wrote:
> - the ideal case for using middleware is that _nothing_ should be 
> added to
>   blender except for a _generic_ interface for communication of "objects"
>   with the external world; the choice of concrete middleware is then 
> to be
>   reduced to a _runtime configuration_ option.

Runtime configuration of the middleware would be a great way to push for 
a clean interface.  I would add that, regardless of whether the 
configuration be runtime or compile-time, it would be important to 
support *from the start* at least two (and ideally more) middleware.  
This gives a bottom-up pressure for a clean, generic interface, to 
complement a top-down design effort.  I don't think I'm saying anything 
new here, I just wanted to make this more explicit.

> - there exists a specific "middleware" for computer animation software,
>   namely "Verse" <http://en.wikipedia.org/wiki/Verse_protocol>. I don't
>   have the feeling that the open source project around it is very active
>   still...

Adding to the list, Nick Porcaro had success interfacing with Blender 
via OSC:
   http://opensoundcontrol.org/introduction-osc
This came out of the music world but seems to have grown far beyond that.

> If so, separating the "object definitions" from
> the "inter-process communication" is a Good Thing, and middleware 
> should be
> evaluated along these directions.

I agree with that.  In my experience, middleware corrupts everything it 
touches with hard-to-remove dependencies, so it is best kept at 
arms-length.  With YARP (which I work on) our goal was for it to be 
"reluctant middleware, with no desire or expectation to be in control of 
your system".  But it is still non-trivial to take code that uses YARP 
and port it to a different middleware, unless the original authors are 
careful in the way Herman is suggesting.  And that seems like a waste, 
limiting the code to a smaller pool of users than it would have otherwise.

Cheers,
Paul