eclipse-score / eclipse-score/communication

Improvement: Introduce GenericSkeleton for Type-Independent Service Provisioning

Open
#76 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
62
Forks
97
Avg merge
1d 1h
Merged PRs (30d)
72

Description

### What

The current mw::com skeleton framework, based on score::mw::com::impl::Skeleton, is strongly typed. This means that a service provider (skeleton) must have compile-time knowledge of the data types for all the events and fields it offers.

This model is effective for many applications but presents a significant limitation for components that need to operate on services dynamically. The primary use case is a Gateway. A gateway's core function is to route or translate data between different protocols or domains (e.g., LoLa to SOME/IP or DDS or Vice Versa, or between different security domains). Such a component cannot be recompiled for every possible service it might need to provide; it must be able to discover and offer services at runtime based on deployment configuration.

### How

We propose the introduction of a new GenericSkeleton class. This class will act as a type-erased counterpart to the existing Skeleton.

The core concept is to allow events to be defined at runtime by specifying their properties (name, size, and alignment) programmatically, rather than through C++ template arguments.

Key Design Goals:

Type-Erasure: The skeleton's interface should not depend on the C++ SampleType.
High Performance: The API must provide a zero-copy mechanism for sending data to match the performance of the existing typed skeleton.
Safety: The API must be designed to prevent common memory errors, such as buffer overflows, when using the zero-copy path.
Flexibility: The API should be easy to use for simple cases while providing maximum performance for demanding ones.

The proposed design introduces GenericSkeleton and GenericSkeletonEvent, which uses a GenericSampleWriter helper class to ensure safe memory access.

Image

### Estimates for realization

5 weeks after validation acceptance of the improvement and design.

### Category

- [ ] Affects Detailed Design

### Requirements / Architecture

- [x] Requirements / Architecture are not affected by this change?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.