In the course of the last two years, I've grown extremely frustrated with the way Ruby code is distributed within rock-core packages.
As an example, let's look at the transformer: drivers/transformer is the *implementation* of a transformer-like functionality in C++ drivers/orogen/transformer/rock/transformer.rb is the orogen plugin that gives access to drivers/transformer in oroGen drivers/transformer/ruby implements a *model* of a transformer tree in Ruby, which has no relationship whatsoever with the C++ library (apart from the name) drivers/transformer/ruby/syskit is both a generic implementation of frame annotations in a component network *and* the runtime setup of oroGen components that use the transformer orogen plugin 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) Moreover, I'd like to split the ruby "framework-free" library from the Syskit and oroGen bits. I've wanted to do the same for typelib and oroGen at some point, and was thinking about getting all the "modelling" bits under the modelkit- umbrella, the component-level runtime bits under the runkit- umbrella and then orogen- and syskit-, e.g. 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 This would give me a frame into which the Gazebo integration (which follows the same kind of mess than the transformer) could be finally organized: tools/modelkit-sdf: modelling related to SDF (orogen modelling of a Gazebo instance, SDF loader for the transformer) tools/runkit-sdf: loading a SDF file into a vizkit3d instance, optionally linking to a running Gazebo instance. tools/syskit-sdf: using SDF to auto-configure a system in Syskit, integration of Gazebo in Syskit. While the namespaces would change, getting backward-compatible aliases won't be a big deal since the code/APIs won't change (at least, not right away) 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. Sylvain _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
