Closed pelikhan closed 3 years ago
Summarizing discussion with @pelikhan
A robot shield (device XY99), which is controlled by JD and has:
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.
servoX
and ledX
- unique name for each client; then there is only 4 options for each serviceXY99:1:1
, XY99:2:2
, XY99:3:3
, XY99:4:4
reasoning that servo and LED ports are relatedA 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).
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.
Instead of having a flat name space, how about a hierarchical one? So you could naturally group the servo/LED together.
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.
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.
The multi sensor devices is an example of device affinity between services.
Humidity/barometer/temperature often come together
So for the record the current plan is to:
left_leg/acc
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.
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.