Closed cjdcordeiro closed 5 years ago
Suggested names:
{
identifier: str, # (required) something like "046d:082d"
name: str, # (common attr) something like "Logitech, Inc. HD Pro Webcam C920"
parent: ref, # (common) reference to the nuvlabox_resource
available: boolean, # (required) true/false
host-device-path: str, # (optional) something like "/dev/bus/usb/001/001", whenever we can get that
interface: { USB | BLUETOOTH | GPIO | ... }, # (required) hardware interface the peripheral is using
adapter: str # (optional) doesn't really apply for peripherals, but more for embedded hardware sensors. Maybe we don't want to track those. If so, then just discard this attr
}
The first version looks good in general. Specific comments:
Presumably these resources will need to be versioned along with the other nuvlabox resources. A 'version' field will be required in that case.
The schema as it is provides very little opportunity for automated matching between applications and devices. Essentially the only fields with reliable values are interface/protocol and available. This isn't enough to distinguish between cameras, microphones, thermometers, etc. Is automated matching a goal, or will the matching always be manual?
The first version looks good in general. Specific comments:
- I'd prefer 'nuvlabox-peripheral' to keep all of the nuvlabox resources together.
👍
- For the application specification of devices, either this should be constraints on specific fields of the nuvlabox-peripheral resource or a standard CIMI filter against those fields. Truly free text wouldn't be useful for matching or allocation of devices.
the thing is that when you are defining the application, you don't know yet which NuvlaBox you're going to deploy to so you can't match against any peripherals. And even if you'd match against existing peripherals, the actual field we want here is the host-device-path
, which we might not always know.
- I'd prefer 'protocol' over 'interface', as I find interface too general.
That was my first though but then, USB isn't a protocol for example. What all peripherals have in common is that they are all connected to the NuvlaBox via a hardware interface
- I think that 'host-device-path' can probably just be simplified to device.
👍
- Unless there's a concrete example for 'adapter', it would be better left out.
There are examples (ISA adapter, SMBus nForce2 adapter at 4d00, etc...https://wiki.archlinux.org/index.php/Lm_sensors). The thing is that these are all embedded sensors, and not really peripherals. Should we manage these as well? Or don't report them at all?
Presumably these resources will need to be versioned along with the other nuvlabox resources. A 'version' field will be required in that case.
The schema as it is provides very little opportunity for automated matching between applications and devices. Essentially the only fields with reliable values are interface/protocol and available. This isn't enough to distinguish between cameras, microphones, thermometers, etc. Is automated matching a goal, or will the matching always be manual?
the information about the type
of sensors is not a property of the peripheral. Usually this info is gathered from the peripheral description. That's why I was proposing to put it in name
. A type
field would be useful, but I'm sure the automated matching would need to be done by us on the NuvlaBox, and would be limited
@cjdcordeiro Ok, so we agree that automated matching of peripherals is out of scope and won't be supported?
@loomis not for now at least. Can always be added later on.
@loomis a few extras for the schema:
it might be useful to have an attribute that helps identifying who discovered that peripheral. This will help us and the user understand whether it was and which nb component reported the peripheral or whether it was created manually by a user. something like source
or discovery
other optional attributes could be: vendor
and model
required class
or type
, where we can put whether it is an "AUDIO", "VIDEO", "HUMAN", "UNKNOWN" kind of device
This ticket is about planning for the new server resource which shall be associated with the NuvlaBox resource, and comprise all the peripherals on the NuvlaBox, which can then be mapped onto a Nuvla application