[Rust API] Service discovery API [2025-09-25]

[darkwisebear]

Participants

@darkwisebear
@MarkSchmitt
@HartmannNico
@FScholPer

Agenda

1. Discuss Basic com-api structure for different IPC providers build inc_mw_com#13.
2. Discuss service discovery model
   • How to do service discovery event driven?
   • How to treat services that are already available when SD is started?
   • Does it make sense to also announce the absence of services? If yes, how?
3. API discussion
   • Complete InstanceSpecifier. Do we have an InstanceIdentifier? Or would we cover this already with the ConsumerBuilder?
   • Sync vs. async

Minutes

[darkwisebear]

When and how to choose the backend

• The user chooses the backend based on which implementation of Runtime is used in the code.
• This can be done by impl Builder<CustomBackend> for RuntimeBuilderImpl or by providing an extra crate that provides the implementation for Runtime.
• Feature flags can be used to add or remove backends provided by the central crate(s). We do not use them to select the backend during build time.

[vinodreddy-g]

@darkwisebear Is there a different meeting invite for rust api discussion? Or this will be discussed in communication FT?

[darkwisebear]

@vinodreddy-g I hijacked the "Service Discovery" API design meeting to discuss this topic with other people. If you want we can also invite for a separate meeting to discuss this.

[vinodreddy-g]

@darkwisebear Yes a meeting would be good to discuss this .
One proposal for time from our side would be tomorrow at 9:15 am.
Would you invite?

[darkwisebear]

Nope, no time then. I'll send an invite, but not then.

[darkwisebear]

I don't really know how to setup meetings (edit: in the score context), so please use this Teams link to join today at 1:30 pm CEST if you are interested (@vinodreddy-g @pawelrutkaq @piotrchodorowski).

https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZmVkOWQ3YTItOTk3My00YWQ2LTk4MDYtYzFjNWI5ODIyNWJj%40thread.v2/0?context=%7b%22Tid%22%3a%22ce849bab-cc1c-465b-b62e-18f07c9ac198%22%2c%22Oid%22%3a%227fafb50b-4142-4c6e-afc3-698a75af0d05%22%7d

[vinodreddy-g]

@darkwisebear we will join.Thanks

[darkwisebear]

Service discovery model

Brainstorming:

1. Invent a special interface that provides an event that announces newly available interfaces.
2. Provide an async method that allows for waiting for a service. If the service is already there, the future immediately resolves.
3. Do not explicitly use SD; instantiate consumer and either check connection status or just use and manage connection status through error handling / timeout handling.

Conclusion: We need two API levels:
Lowlevel: The user can create an object for a specific Interface/InterfaceSpecifier combination. TBD: How will service availabilities be communicated?
High level: ConsumerBuilders allow for the direct usage of an InstanceSpecifier (specific!). The connection will then be established in the background; sync methods will return errors, futures will immediately resolve to an error, streams will deliver errors.

[darkwisebear]

Draft PR with changes from workshop

eclipse-score/inc_mw_com#15

[FScholPer]

Can we reuse the https://github.com/eclipse-uprotocol/up-spec/blob/main/basics/uri.adoc for the discovery?

[darkwisebear]

Might be reasonable. We would also need to determine whether version information is only part of the type or also part of the instance. The uP URI suggests that it's part of the instance, which makes sense in case the version only specifies behavior (e.g. a minor version change) but in case of breaking / binary incompatible changes it also becomes part of the type - which again also indirectly makes it a property of the instance.

[darkwisebear]

We should maybe discuss this in the Communication FT meeting today? However, I'm not sure whether I can participate today...