Structure Proposal¶

Requirements¶

In general, the following requirements try to enforce the general reusability of data types.

• Visibility: Data definitions must be easily visible when searching for them to foster reuse. This includes:
  • Folder browsing
  • Code completion
• Structuredness: A structured view on the data is required as an orthogonal perspective to the general visibility in order to find functionally coherent groups of data definitions.
• Stability: A core set of data definitions must be kept stable as much as possible in order to shield depending software from frequent changes.
• Extendability: New data type definitions are constantly required. Adding them to the repository must have a low barrier to motivate data type sharing.
• Addressability: A certain revision of a data type must be uniquely addressable and accessible in order to conserve system states.
• Practicability: Data type definitions must be usable in an efficient manner in all target languages. This includes also the use of languages where IDL definitions are parsed at runtime and not compiled statically.

Proposed Solution¶

Packaging¶

• RST will be split into two separate libraries. Both libraries will be built by the same build-system and use the same naming and structure conventions.
  • RST: stable data type definitions. Types in this library must not use types from beta.
  • RST-beta: new data type definitions which may be modified constantly. Beta-types may include types from stable.
• Using the beta library will require explicit requests from the application developer, e.g. by using a separate pkg-config file. Also, e.g. for C++, the headers will be separated into different subdirectories in a way that using the stable library will not make the headers of the beta library automatically available to the compiler.

Data Type Integration Procedure¶

• New data types can be added by every developer to the beta library using the specified style guide.
• The RST team will merge the data types from beta to stable from time to time. During this process modifications to the data are explicitly allowed in order to meet the style and quality requirements of the stable library.
• We will shortly integrate fundamental data types instable inspired by ROS, Orocos etc.

Structure¶

• The svn will contain a single tree for organizing the data definitions. This tree (i.e. the definition of appropriate categories) will be inspired by the data layout of ROS, Orocos and other robotics middlewares.
• Folders in the match the package provided in the IDL files.
• A Redmine plugin will be created to browse the list of data types, e.g. in a flat list for easy search.

Versioning¶

• No manual versioning will be used. Especially, no versions will be synchronized with RSB releases. Instead, svn revisions will be the only means of addressing specific versions. svn revisions will be integrated into the library for using them in the code or with the C++ preprocessor.

Style Guide¶

• A style guide will be defined (or the current one will be improved) to cover more aspects, e.g. like the canonical format for the java_outer_classname option.
• Even if some contents of the files can be defined canonically, we will not generate them using the build system.
• The style guide will explicitly define that data type names do not contain artifacts of their current application. E.g. if a something is used as an event, the data type name must not contain the an event suffix or prefix.

Addressed Requirements¶

Identified Drawbacks¶

• Python naming of modules