[Rust API] Finalizing rust APIs

[bharatGoswami8]

Participant

12-Nov Meeting :

@darkwisebear
@pawelrutkaq
@bharatGoswami8
@sankurm
@rpreddyhv
@lurtz

25-Nov Meeting :

@darkwisebear
@pawelrutkaq
@bharatGoswami8
@rpreddyhv
@piotrchodorowski
@awillenbuecher-xq-tec

Background

• When we move the find_service and producer_builder APIs into the Runtime trait, we need to implement ConsumerBuilder and ProducerBuilder using a generic or dynamic interface instead of the static interface generated from files.

https://github.com/eclipse-score/inc_mw_com/blob/main_api_rs/com-api/examples/com-api-gen/com-api-gen-lola/src/lib.rs#L87
https://github.com/eclipse-score/inc_mw_com/blob/main_api_rs/com-api/examples/com-api-gen/com-api-gen-lola/src/lib.rs#L75

• As a result, ServiceDiscovery and ProducerBuilder now support any interface rather than being tied to specific generated interfaces

Agenda

12-Nov

1. Move find_service and producer_builder APIs into the Runtime trait, and make ServiceDiscovery and ProducerBuilder implementation generic for Interface type.
2. The find_service API currently uses a polling mechanism. To reduce overhead and avoid continuous polling, we should consider an event-driven approach leveraging futures or asynchronous APIs.
3. Review SampleContainer implementation: It currently uses VecDeque , which introduces heap allocations at runtime and violates the API design principle of avoiding heap usage during the running phase. Should we refactor it to use a compile-time fixed capacity via const generics (e.g., SampleContainer<S, const CAPACITY: usize>) to guarantee zero runtime allocation?

25-Nov
discussion on open point of regarding PR eclipse-score/inc_mw_com#17.

• Do we need instance_id set during building the producer.
• Validation of service name 
• Introduce PlacementDefault trait and provide write_in_place<T: PlacementDefault>(&mut self) API for standardized in-place initialization.
• Reloc trait impl for types
• Naming of GATs in runtime traits.

Meetings of Minutes

//12-Nov-25

• In the generic approach (Option-2) question : Consumer and subscriber trait will turn to generic using Runtime.
  and instead of instance-specifier it will pass InstanceInfo (all the info of runtime),
  And subscriber required identifier as str.
• Cons Option-2) - yes lib need to use generic , we will look for dynamic compatibility for Runtime trait to remove generic dependency.
• next week mid of we will share the feasibility of lola compatibility with option 2.
• Create additional channel in slack for discussion.
• Async API for find service - get Instance will be added on ServiceDiscovery trait.

Meetings of Minutes

//25-Nov-25

1. Decision for Do we need instance_id set during building the producer

• Remove from InstanceSpecifier ANY const and do something ,so InstanceSpecifier is always pointing to the exact service instance .

• ConsumerBuilder .find will return an iterator to InstanceSpecifier and not InstanceId

2. Decision for Validation of service name

• Enforce format in concept level (backend agnostic) as described in doc of InstanceSpecifier

4. PlacementDefault trait will be introduce on upcoming PR by @pawelrutkaq

5. Reloc file can be implemented for all the type and macro will be enable by @pawelrutkaq on next PR.

6. As of now going with existing naming.

7. Discussion about basic design of Asyn find service APIs

[pawelrutkaq]

@bharatGoswami8 please include me in meeting ;) [email protected]

[pawelrutkaq]

2. Definitely we shall provide async api.
3. We here can also consider either generics or a runtime fixed size (alloc at init only) container. Or both. This kindof depends on if contaner is mostly on stack or as a member of some struct which could have runtime config provided for that.

[darkwisebear]

@bharatGoswami8 please add @lurtz to the list of participants and invite.

[bharatGoswami8]

@lurtz , Could you please share your email id for meeting invite ?

[lurtz]

@bharatGoswami8 I am uneasy to share my E-Mail address here. Are you reachable via Slack? I was not able to find you

[bharatGoswami8]

@lurtz
I hope you have already meeting invite with subject - eclipse-score-discussions for score::com Rust APIs
And it is scheduled for 12th Nov at 10:00 AM CET.

[lurtz]

@bharatGoswami8 I got it. I have to leave it for approximately 30minutes from 10:30 to 11:00. I hope that is fine

[bharatGoswami8]

@darkwisebear , @pawelrutkaq , @lurtz , @awillenbuecher-xq-tec ,

Discussion is scheduled for 12th Nov at 10:00 AM CET.

[pawelrutkaq]

Hello colleagues. I have documented the approaches we can take for the generic implementation of com-api to help with the discussion. @darkwisebear @lurtz @bharatGoswami8

The options, from my stand, for implementing generic com_api

Option 1

Provide a generic com_api so that user is able to use all steps (building producers/consumers, getting samples etc) without the need to know runtime-specific implementation.

The solution is assuming that we will generate code (The Producer types Consumer Types, Interface type)
per runtime This means that if we support runtime Implementations A, B, C there will be A-gen, B-Gen, C-gen
of those types. Keep in mind, this does not matter for the end use,r as this type will expose the same, the consistent behavior.

pub struct VehicleOfferedProducer {
    pub left_tire: RuntimeImplementation::Publisher<Tire>,
    pub exhaust: RuntimeImplementation::Publisher<Exhaust>,
}

// HERE: Now generated code has access to very specific impl details so it can
//easily build itself from internals
impl TryFrom<RuntimeConsumerBuilder> for VehicleConsumer {
    type Error = com_api::Error;
    fn try_from(_builder: RuntimeConsumerBuilder) -> Result<Self> {
         todo!("VehicleConsumer::try_from")
    }
}

To solve the testability issue, we would make sure that A-gen, B-gen, C-gen simply provide a feature flag, ie. mock that will expose the same types but with mock ability.

Example https://github.com/qorix-group/inc_mw_com/tree/example_trait_impl/com-api . Look only for mock impl part.

Option 2

Provide the generic com_api along with the generic generated part. It means that also generated part will be
generic and will not know the runtime implementation.

pub struct VehicleOfferedProducer<R: Runtime> {
    pub left_tire: R::Publisher<Tire>,
    pub exhaust: R::Publisher<Exhaust>,
}

This option automatically solves the problem of testability as the user can simply in testing inject VehicleOfferedProducer<MockRuntime>.

Pros and cons

Option 1

pros

• the types are always the same, no generic code is carried over/forced
• type builders are aware of the exact runtime implementation, so they can be created anyhow

cons

• testability needs a feature flag used in the build system (not in code)

Option 2

pros

• testability is easy

cons

• will force the whole code base to become generic over runtime. In particular, all middleware modules that will use com will become generic over it. This can cause high nesting of generics. (can we solve it?)

// This caries over to any depth level of code.
pub struct CameraDetection<R: Runtime> {
    some_other: SomeOtherClass<R>
}

pub struct SomeOtherClass<R: Runtime> {
    vehicle: VehicleConsumer<R>
}

questions

• how we going to build certain types, ie. VehicleConsumer from the generic runtime, not knowing it's
  certain implementation

[bharatGoswami8]

@darkwisebear , @pawelrutkaq , @lurtz ,

As discussed in 12-Nov meeting , PR created for discussed design approach -
eclipse-score/inc_mw_com#17

[bharatGoswami8]

@lurtz , @darkwisebear , @pawelrutkaq , @sankurm , @rpreddyhv

Discussion scheduled on 25 - Nov at 9:30 AM CET for open point of regarding PR eclipse-score/inc_mw_com#17.

• Do we need instance_id set during building the producer.
• Validation of service name
• Introduce PlacementDefault trait and provide write_in_place<T: PlacementDefault>(&mut self) API for standardized in-place initialization.
• Reloc trait impl for types
• Naming of GATs in runtime traits.

[bharatGoswami8]

Meetings of Minutes
//25-Nov-25

Decision for Do we need instance_id set during building the producer
Remove from InstanceSpecifier ANY const and do something ,so InstanceSpecifier is always pointing to the exact service instance .

ConsumerBuilder .find will return an iterator to InstanceSpecifier and not InstanceId

Decision for Validation of service name
Enforce format in concept level (backend agnostic) as described in doc of InstanceSpecifier
PlacementDefault trait will be introduce on upcoming PR by @pawelrutkaq

Reloc file can be implemented for all the type and macro will be enable by @pawelrutkaq on next PR.

As of now going with existing naming.

Discussion about basic design of Asyn find service APIs

[bharatGoswami8]

Updated latest commit on PR for concluded points - eclipse-score/inc_mw_com#17

[bharatGoswami8]

Participant

@bharatGoswami8
@darkwisebear
@pawelrutkaq

Agenda

• Introduce ProviderInfo trait for offer/unoffer API support in runtime crate, we have Offer trait but that is implemented in Generated file which is independent of runtime because of that we need this trait support which will help to implement backend implementation.
• Marker trait support for all the type bound trait as super trait for type T

`pub trait CommData : Send + Clone + Debug + 'static {}
so T can be used like - T: CommData`

• Introduced TypeInfo trait to provide the type id support, and can we make this as part of CommData trait as super trait.

Meetings Minutes

• We can go with providerInfo trait to support the offer and unoffer API of backend .
• We will implement CommData trait which contains the TypeID information and bound with all the type related traits

`pub trait CommData : Send + Reloc + Debug + 'static {
const ID: &'static str;
}

• @bharatGoswami8 will create PR on SCORE-Communication for with above design update for review.

• Lola support for com-api with initial API support will be ready soon.

[bharatGoswami8]

Instead of PR, created Improvement ticket - eclipse-score/communication#141

[bharatGoswami8]

For CommData Trait detail added on ticket - eclipse-score/communication#127