Prepare next release

[LittleHuba]

What

Prepare the next release of communication

How

No response

Estimates for realization

a

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[crimson11]

This information shall be added to the release notes:

GenericSkeleton support temporarily disabled

score::mw::com now contains a GenericSkeleton, which is semantically the counterpart to the existing GenericProxy. I.e. it allows to create a service-provider instance during runtime based on configuration/meta-info without the need of strong C++ typing, which a "normal" skeleton/skeleton-field/skeleton-event has. Due to the following bug: #311 , the functionality will be disabled in the public API, by removing score::mw::com::GenericSkeleton from the types.h header. When the bug has been resolved, score::mw::com::GenericSkeleton will be made visible again.

[crimson11]

This information shall be added to the release notes:

Method Support Status

• Signature of user provided method-handler is not final.
  Currently the wrong assumption is, that for a service-method with signature ReturnType(InArgType1, InArgType2, ...) the user provided handler signature is `ReturnType(InArgType1&, InArgType2&, ...).
  In the final state the expected signature will be: void(ReturnType&, const InArgType1&, const InArgType2&, ...), which saves a copy as it expects the user provided handler to write its result directly in the target location.
• Specifying, which methods to use on consumer side: As an optimization, we require, that the consumer/proxy side announces during proxy-creation, which of the service-methods of the service interface it is going to use. Currently the API requires to hand this information over in form of a string-list of method-names in Proxy::Create(). This will be changed. In the final implementation this information is read from the service-instance deployment in mw_com_config.json
• No detailed/complete tests right now: General functionality should work, but no border cases tested as of now.

Field Get/Set methods currently not fully functional -> WIP

• score::mw::com::impl::ProxyField and score::mw::com::impl::SkeletonField have been extended for Get/Set support.
• The signatures of these (user facing) classes are final.
• The implementation of Get/Set on the skeleton side is still WIP.
• The configuration is not final: The goal is, that the user shall be able to configure in the mw_com_config.json, whether he is going to use a GET/SET method at all if it is available as per the interface-definition. (see release-notes regarding methods above)

[bharatGoswami8]

Rust API side update -

Deprecated old Rust APIs for communication and requested consumer to please adopt the new Rust API (Library). For more details, see //score/mw/com/impl/rust/com-api documentation.

Brief Summary of new Rust COM API Library / APIs

• Backend‑Independent Architecture: A fully independent backend crate enables seamless switching of runtime backends without requiring any changes to user‑level applications.

• Registry‑Based FFI Layer: A flexible foreign‑function interface that facilitates communication between C++ and Rust components.

• MW::COM‑Enabled Runtime (lola-runtime): Provides backend support for the COM module