Rust::com Field APIs design and example of usage by bharatGoswami8 · Pull Request #700 · eclipse-score/communication

bharatGoswami8 · 2026-07-14T05:41:49Z

Added field-based publish/subscribe with field get/set and asynchronous field subscriptions.
Extended interface macros to support field members and generated producer/consumer and compile-time offer API enable.
Added a new example demonstrating offered field producers and consumer field updates.

#579

* Created field interface APIs * Updated SampleMut to use in field as well

* Added field related files on build target

* Created impl block in Lola Runtime for field Producer and Consumer trait

* Mock Runtime impl block added for field APIs

* Updated Interface macro to generate field related types and APIs

* Create proc macro for field init and set handler validation before offer call

* Updated Runtime GATs for field public types * Updated Runtime implementation

* Updated example file with Field APIs usage

bharatGoswami8 · 2026-07-14T05:52:37Z

 ///   "left_tire" and "exhaust" events.
 /// - `VehicleOfferedProducer<R>` struct that implements `OfferedProducer` trait for offering
 ///   "left_tire" and "exhaust" events.
+// TODO: We need to enable the support for mixed types (Event, Method, Field) in the same interface definition.


ticket for same - #701

* Updated the TODOs and documentation

* Clone bound removed from fieldPublisher trait and impl block

* Producer trait offer API limitation added to avoid direct use

rpreddyhv · 2026-07-20T09:57:24Z

+// Below function just demonstrate the field APIs usage
+// This build fine but it can not run because we have not implemented the field APIs in Lola runtime yet.
+
+// Producer creation and intialization of fields with initial values and set handlers for the fields
+// It will return the offered producer instance which can be used to update the fields.


Suggested change

// Below function just demonstrate the field APIs usage

// This build fine but it can not run because we have not implemented the field APIs in Lola runtime yet.

// Producer creation and intialization of fields with initial values and set handlers for the fields

// It will return the offered producer instance which can be used to update the fields.

// Below function demonstrate the field APIs usage

// This builds fine, but it cannot run as the field APIs in Lola runtime are not implemented yet.

// Producer creation and intialization of fields with initial values and set handlers for the fields

// It will return the offered producer instance which can be used to update the fields.

rpreddyhv · 2026-07-20T09:59:22Z

+            // TODO: in working example add that logic to demonstrate the set handler usage.
+            // Note: I think producer may be need clone ?
+        })
+        .expect("Failed to register set handlers")


Why would register_* ever fail? As discussed for Method, it shouldn't return Result.

rpreddyhv · 2026-07-20T10:00:02Z

+        .register_set_handler_left_tire(move |val: &Tire| {
+            println!("Received tire pressure update: {:?}", val);
+            // Additional logic to handle the tire pressure update can be added here
+            // For example, we can increment value or conver unit and update the field again.


Suggested change

// For example, we can increment value or conver unit and update the field again.

// For example, we can increment value or convert unit and update the field again.

darkwisebear

I mainly reviewed the concept part; I think we need to nail that part before it makes sense to look at the rest.

darkwisebear · 2026-07-27T08:05:29Z

 * SPDX-License-Identifier: Apache-2.0
 ********************************************************************************/

+#![allow(unused)]


Please put this to the specific places and do not globally turn it on for the module.

darkwisebear · 2026-07-27T08:41:37Z

+    // Must register handlers and initialize all fields before offer() is available
+    let offered = producer
+        .init_field()
+        .register_set_handler_left_tire(move |val: &Tire| {


I wonder whether &Tire is correct. Why not hand over ownership to the callable? This way, the implementer wouldn't have to clone the value in the likely case the value is written somewhere.

darkwisebear · 2026-07-27T08:43:52Z

+            println!("Received exhaust update");
+        })
+        .expect("Failed to register set handlers")
+        .update_left_tire(&initial_tire_value)


Why by-reference? This forces cloning as the implementation most likely has to clone the value to send it across the network. It might be a corner case, though.

darkwisebear · 2026-07-27T08:47:35Z

+use std::fmt::Debug;
+use std::future::Future;
+
+#[allow(dead_code)]


Why is this dead code?

darkwisebear · 2026-07-27T09:15:36Z

+#[allow(dead_code)]
+// Temp for build test
+// We will remove this once memory layout of same created in rust side like SamplePtr.
+#[repr(C)]


Doesn't this trigger an "improper_ctypes" lint? Result isn't #[repr(C)], so it cannot be used here properly.

darkwisebear · 2026-07-27T09:21:50Z

+// or by default we will enable for user,
+// -> we can keep it default enable as of now,
+// and later we can add tag based mechanism if required because Interface side we need to check how we can do this
+// 2. We are offering get method after subscrption async but before subscription it is sync,


Just turn the one before subscription into async. Or is there anything that prevents you from doing so?

darkwisebear · 2026-07-27T09:24:17Z

+// we will create a module which will have common trait for event and field which will be used by both event and field as a super trait and
+// for this we need to create marker trait for event.
+
+use crate::*;


Please import specific types. Yes, it's tedious, but being explicit here also saves some headaches.

darkwisebear · 2026-07-27T09:33:59Z

+    /// # Returns
+    /// Return the result of `Result<()>` which contains the status of the register operation.
+    // TODO: Do we need to make callback lifetime 'static or we keep same as field publisher lifetime.
+    fn register_set_handler<'a>(&self, callback: impl Fn(&T) + Send + 'a) -> Result<()>;


There is no equivalent method for registering the get handler. It may sound weird, but the C++ counterpart has that, since mw::com treats set and get as ordinary methods.

darkwisebear · 2026-07-27T09:34:59Z

+    /// # Returns
+    /// Return the result of `Result<()>` which contains the status of the register operation.
+    // TODO: Do we need to make callback lifetime 'static or we keep same as field publisher lifetime.
+    fn register_set_handler<'a>(&self, callback: impl Fn(&T) + Send + 'a) -> Result<()>;


TO me this feels as if we're treating ordinary methods and field methods in a distinct way. Maybe we should think about getting methods ready first and then incorporate them as the foundation of set and get here.

darkwisebear · 2026-07-27T09:36:08Z

@@ -329,18 +342,10 @@ where
 ///
 /// # Type Parameters
 /// * `T` - The relocatable event data type
-pub trait SampleMut<T>: DerefMut<Target = T> + Debug
+pub trait EventSampleMut<T>: SampleMut<T>


Is this just because of update vs send (aka naming)?

bharatGoswami8 added 8 commits July 13, 2026 11:51

Rust::com Create the Field APIs

cec5766

* Created field interface APIs * Updated SampleMut to use in field as well

Rust::com Update the build target

29b56a4

* Added field related files on build target

Rust::com Added interface impl block in Lola Runtime

cbb2e98

* Created impl block in Lola Runtime for field Producer and Consumer trait

Rust::com Update the Mock Runtime for field APIs

419ec88

* Mock Runtime impl block added for field APIs

Rust::com Interface macro update

74990d2

* Updated Interface macro to generate field related types and APIs

Rust::com Create type state macro for field Init

b91fb41

* Create proc macro for field init and set handler validation before offer call

Rust::com Update the Runtime GATs for field interface

7558ed0

* Updated Runtime GATs for field public types * Updated Runtime implementation

Rust::com Update the example app with Field APIs usage

e3242bc

* Updated example file with Field APIs usage

bharatGoswami8 requested review from LittleHuba, bemerybmw, castler, crimson11, hoe-jo and limdor as code owners July 14, 2026 05:41

github-project-automation Bot added this to COM - Communication FT Jul 14, 2026

github-project-automation Bot moved this to Backlog in COM - Communication FT Jul 14, 2026

bharatGoswami8 self-assigned this Jul 14, 2026

bharatGoswami8 requested review from darkwisebear and pawelrutkaq July 14, 2026 05:42

bharatGoswami8 force-pushed the Rust_Field_APIs_Desing_and_Example branch 2 times, most recently from 70fbb6e to f7cd859 Compare July 14, 2026 05:45

bharatGoswami8 commented Jul 14, 2026

View reviewed changes

Rust::com Update the documentation for macro

9e7f74e

* Updated the TODOs and documentation

bharatGoswami8 force-pushed the Rust_Field_APIs_Desing_and_Example branch 2 times, most recently from 6921668 to 6faaa6c Compare July 14, 2026 06:11

Rust::com Remove the Clone bound from FieldPublisher

21d958d

* Clone bound removed from fieldPublisher trait and impl block

bharatGoswami8 force-pushed the Rust_Field_APIs_Desing_and_Example branch from 6faaa6c to 21d958d Compare July 14, 2026 06:23

bharatGoswami8 added the rust-api label Jul 14, 2026

Rust::com Add limitation to offer API of interface trait

8589c65

* Producer trait offer API limitation added to avoid direct use

bharatGoswami8 force-pushed the Rust_Field_APIs_Desing_and_Example branch from 30e0af1 to 8589c65 Compare July 19, 2026 08:53

anmittag moved this from Backlog to In Progress in COM - Communication FT Jul 21, 2026

rpreddyhv reviewed Jul 24, 2026

View reviewed changes

darkwisebear suggested changes Jul 27, 2026

View reviewed changes

	// For example, we can increment value or conver unit and update the field again.
	// For example, we can increment value or convert unit and update the field again.

Uh oh!

Conversation

bharatGoswami8 commented Jul 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rpreddyhv Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

darkwisebear left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rpreddyhv Jul 20, 2026 •

edited

Loading