role manager should bind to device + service index

[pelikhan]

This would allow binding to a service that is not unique on a device.

example: device has multiple buttons, need to be able to bind to specific buttons.

[mmoskal]

Summarizing discussion with @pelikhan

Scenario: quad-servo

A robot shield (device XY99), which is controlled by JD and has:

• 4 different servo controllers
• 4 different LED controllers

The user plugs their own LEDs and servos. They glue an LED to a servo to light it up while it's moving.

They define roles servoA, servoB, servoC, servoD for both servo client and LED client.

Each of these roles can be bound to: XY99:1:1, XY99:1:2, ..., XY99:2:1, XY99:2:2, ..., XY99:4:4 (16 entries), that would need to sit in drop-down next to servoX.

If there was also 4 motor controllers, we would get 64 options. This is clearly untenable.

Possible fixes

• (F0) force the user to use servoX and ledX - unique name for each client; then there is only 4 options for each service
• (F1) only allow XY99:1:1, XY99:2:2, XY99:3:3, XY99:4:4 reasoning that servo and LED ports are related
• (F2) disallow more than one instance of each service in a device - ie. the robot would have to expose 4 devices, each with a single servo and LED controller; here we lose the natural ordering we have with multiple services
• (F3) like (F2), but implement servos service, which allow to control multiple servos; potentially we would have to do that for every service though

Scenario: gyro+accel sensor

A typical gyro would also expose accelerometer (they are usually in a single chip). The user may want to use a common name, say left_leg for both to indicate they want the two sensors co-located on a single device.

With (F0) this is no longer possible. The user would have to say left_leg_acc and left_leg_gyro. The common prefix could possibly be still used to hint to the auto-binder to co-locate these. This also gives the binder more flexibility, in case there actually are separate acc/gyro sensors, that were glued together by the user.

Generally, I'm leaning towards (F0).

[mmoskal]

Scenario: button with a twist

A button may have additional functionality exposed as an additional service, for example an LED or a vibration motor. The button client may support these, when they are present.

A straightforward way to implement it would be for the client to bind by name to the button service, and then, once bound, do a dynamic lookup on the services exposed by the bound device to see if a LED extension is present.

However, this would somehow need to be communicated on the bus for the software simulation to pick this up and spin up a virtual device if needed. Maybe we just need some extension in role manager for that.

[tballmsft]

Instead of having a flat name space, how about a hierarchical one? So you could naturally group the servo/LED together.

[jamesadevine]

You mean like a... URL? ;)

Best,

James

---

From: Tom Ball notifications@github.com Sent: Friday, January 8, 2021 9:07:05 PM To: microsoft/jacdac jacdac@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [microsoft/jacdac] role manager should bind to device + service index (#130)

Instead of having a flat name space, how about a hierarchical one? So you could naturally group the servo/LED together.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fjacdac%2Fissues%2F130%23issuecomment-756998150&data=04%7C01%7Ct-jamdev%40microsoft.com%7C02ed8d1c65fd40ecf8c808d8b4195acd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457368292221653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3xmvXkZgVn0v9bPtre%2FhKrGc62NqDgmX2tTfgrEVtrY%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABEF4KILO5MA75FUICKZJJTSY5XXTANCNFSM4V2KYW4Q&data=04%7C01%7Ct-jamdev%40microsoft.com%7C02ed8d1c65fd40ecf8c808d8b4195acd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457368292221653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MxWBvFj3wJHiN6o5hUxGNVbTtAGOmnHgoroHWPv%2Fqfc%3D&reserved=0.

[mmoskal]

I like the hierarchical name idea - we would just use left_leg/acc and left_leg/gyro - the part until the first slash is "host name", and services sharing the host name should go on the same device.

[pelikhan]

The multi sensor devices is an example of device affinity between services.

Humidity/barometer/temperature often come together

[mmoskal]

So for the record the current plan is to:

• use fix (F0)
• use hierarchical names like left_leg/acc
• stipulate these prefixes can be used as hints for auto-binding, but leave it unimplemented for now due to various implementation complexities - we would just wait until the actual user-scenarios become clearer
• keep the mapping from device_id:service_idx->role, not the other way around

As for the combination sensors, the same-host hint only matters when there is more than one such combination sensor in the project. Even then, it's only a hint.