eCAL 6

[KerstinKeller]

Context

This issue is present to track the tasks that need to be completed for an eCAL6 release.
We might link other issues here as well.

Things to get done

• Core

  • Configuration Concept eCAL Configuration Concept #1061
    - [x] Hierarchical configuration
    - [ ] mapping of topic names, (6.x)
    - [x] configuration in Pub / Sub / Client / Server APIS
    - [x] file format change (ini -> yaml) (Missing ecaltime.ini) ([config] Remove simpleini as submodule #1806)
    - [ ] merging of configs (6.x)
    - [x] Remove ConstrainedInteger from API

  • Finalize All APIs (Pub/Sub and Client/Server, Util)
    - [ ] Use RAII concepts, (eCAL 7)
    - [ ] Initialize / Finalize (eCAL 7)
    - [ ] Publish / Subscribe API (see also eCAL::core / eCAL::hdf5: per publisher datatype information #1237) (biggest problem atm is the ambivalence between callbacks and receive functionality. The callback contains a lot more information than the receive function. We could even think about splitting this in 2 classes for simplicity (Synchronous Subscriber / Asynchronous Subscriber).
    New V6 API: Constructor with callback similiar to service API, no synchronous receive
    Old V5 API: Implement in terms of V6
    - [ ] Client / Server API - synchronous / asychonous? - possibility to distinguish mutliple servers, ....
    - [ ] eCAL Process API removal (@KerstinKeller invite meeting)
    - [ ] GetMonitoring API (why does it return an int?) (@KerstinKeller invite meeting)
    - [ ] Consider namespaces (Registration / Monitoring / ...)
    - [ ] Carefully review all public API (e.g. Config Types)
    - [ ] What APIs to remove
    - [x] Remove utility functions (e.g. EnableLoopback(bool) ) that became obsolete because of configuration management

  • Domain specific communication? (on demand)
    - should you be able to communicate on different domains
    - global domain vs local domains
    - usecase: multiple simulations on the same PC

  • C++ Styleguide (header naming, namespace naming, ...) - ClangFormat for C++ Style Guidelines (keep consistent)

  • enrich monitoring information with more tracing info (e.g. Latencies (min, max, avg), callback duration, publish acknowledge timeouts)

  • eCAL Logging split send / receive (lower prio)

• Language Support

  • C
    • Adapt to new APIs
  • C#
    • Introduce SDatatypeInformation
    • Rename namespace Continental.eCAL -> Eclipse.eCAL ?
    • Provide eCAL proto datatypes (e.g. for apps, core)
    • The timestamps that eCAL provides as datetime are incorrect. They are not based on microseconds.
  • Python
    • Nanobind binding for eCAL Core
    • Nanobind binding for eCAL Measurement
    • Host binaries on PyPi
  • Rust (?)
  • Protos
    • Install .proto files?

• Serialization support

  • Protobuf / Capnproto / Flatbuffers / Msgpack

• Measurement

  • eCAL::hdf5: enhance API to save information with unique ID. #1338
  • mcap support (v6.1)

• Apps

  • Monitoring plugin API ???

• Testing

  • Extend unit test to test all eCAL Configurations
  • Execute eCAL Tests build with memory sanitizers - and fix the problems

• 3rdparty

  • Check and Update all thirdparty dependencies (Gtest, ...)
  • Update Protobuf to latest version (3.26.1? - as of 24.05.24)

• Wire compatibility:

  • find a way that will allow us to make incompatible changes more easily in the future
    • e.g. per layer version in registration info.

• API compatibility strategy

  • API break in eCAL6, new API reintroduced in eCAL5 (and see if that works)

eCAL 6.x

• RW Locks / Clocklock mutex -> activate and make configurable
• Acknowledged send via TCP?
• New eCAL registration layer (performance)
• Rewrite eCAL_SHM -> many concept ideas (lower prio)
• Tracing