[Rock-dev] Reorg of modelling-related packages

[Sylvain Joyeux]

>> What I'd like to do first and foremost is split the ruby code out of
>> the C++ library. This would make the development cycle in Ruby that
>> much more streamlined (documentation, gemification & tests)
>
> Would you also put language bindings into a separate library?

I'm less clear-cut on that, as the bindings are definitely related to
the core library (a.k.a. I don't mind either way). It would definitely
make it easier on the build side.

>>   tools/modelkit-transformer: what's currently the non-syskit bits of
>> drivers/transformer/ruby
>>   tools/syskit-transformer: drivers/transformer/ruby/syskit/*
>>   tools/orogen-transformer: the transformer/orogen plugin
>
> Why using modelkit-* and not e.g. transformer_ruby as already used for
> other packages?

Because modelkit-transformer is not transformer_ruby the way
frame_helper_ruby is related to frame_helper. It's actual relationship
with drivers/transformer is very loose.

And also because I'd like to gather the "modelling of components"
under the same hood. Long-term, the OroGen::Spec and OroGen::Loader
would go there as well as e.g. modelkit-component and
modelkit-component-rtt

> I would prefer something like syskit-plugin- and orogen-plugin- for clarity

I thought about that. I was following the rubygems convention (XXX-YYY
is YYY plugin for XXX). Moreover, I would rather not put the
syskit/transformer plugin code in the Syskit::Plugin::Transformer
namespace, sticking with Syskit::Transformer (again, a common
convention in the Ruby world).

> Any example for what runkit is supposed to contain?

The low-level runtime bits related to running, visualization and replay.

Long term, hopefully, a generalized and fully unit-tested orocos.rb layer, e.g.

  runkit
  runkit-rtt
  runkit-async
  runkit-pocolog

Regarding the SDF/Gazebo stuff
  runkit-sdf # starting gazebo, setting up a vizkit3d by connecting to
a SDF instance, ...

>> I'm open for better ideas. It does split the code in smaller units -
>> against which there was a strong feeling at the origin of Rock - but
>> I've seen that explaining where is everything is REALLY hard right
>> now, simply because loosely-related things ended up being bundled
>> together.
>
> I would add: because related things are sometimes not clearly or easily
> identifiable. So your proposal would solve that in parts e.g. by
> exposing the plugins a bit more.

Absolutely.

Sylvain