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
  • RST-beta: new data type definitions which may be modified constantly

Data Type Integration Procedure¶

• New data types can be added by every developer to the beta library using a 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.

Structure¶

Addressed Requirements¶

Identified Drawbacks¶

• Python naming of modules