24 lines
1.8 KiB
Markdown
24 lines
1.8 KiB
Markdown
# driver-registry Specification
|
|
|
|
## Purpose
|
|
TBD - created by archiving change device-agent-runtime-foundation. Update Purpose after archive.
|
|
## Requirements
|
|
### Requirement: Driver type registry lives in the driver layer
|
|
The system SHALL provide a registry, owned by the `driver` package, that maps a `driver_type` string (e.g. `"wda"`) to a builder function producing a `DriverFactory` for that type, so that any caller needing to construct a driver for a device does so without importing a concrete driver class directly.
|
|
|
|
#### Scenario: Building a factory for a known driver type
|
|
- **WHEN** a caller requests a driver factory for `driver_type="wda"` with connection info (e.g. `server_url`, `udid`)
|
|
- **THEN** the registry returns a `DriverFactory` that, when invoked, constructs a working `WDADriver` configured with that connection info
|
|
|
|
#### Scenario: Building a factory for an unknown driver type
|
|
- **WHEN** a caller requests a driver factory for a `driver_type` that is not registered
|
|
- **THEN** the registry raises a clear error naming the unsupported `driver_type`, instead of returning `None` or a factory that fails later at connect time
|
|
|
|
### Requirement: Adding a driver type requires no changes outside the driver layer
|
|
The system SHALL allow a new driver type to be added by registering it in the `driver` package's registry alone; no other package (`api/`, `device/`, `tools/`, `runtime/`) SHALL need code changes to support constructing devices of the new type.
|
|
|
|
#### Scenario: API layer is agnostic to registered driver types
|
|
- **WHEN** the console config API resolves a `driver_type` string into a driver factory to register a device
|
|
- **THEN** it does so by calling into the driver registry rather than maintaining its own mapping of `driver_type` to concrete driver classes
|
|
|