1e98ab9ccf
Surface the new platform RPC `GetFlowDefinition` as a typed Dart method so Studio (and other GUI clients) can render an input form before calling `runSavedFlow`. Each declared input arrives as a `FlowInputDef` with the verbatim type tag from the flow YAML — usually `text`, `bytes`, `json`, or `file`. Regenerated proto bindings to pick up the new `GetFlowDefinitionRequest`, `FlowDefinition`, and `FlowInputSpec` message types. Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com> |
||
|---|---|---|
| example | ||
| lib | ||
| test | ||
| tools | ||
| .gitignore | ||
| analysis_options.yaml | ||
| CHANGELOG.md | ||
| pubspec.yaml | ||
| README.md | ||
fai_dart_sdk
gRPC client SDK for the F∆I Platform hub. Used by F∆I Studio
(Tier-2 generic GUI) and any Tier-3 Dart/Flutter domain app
(DigiScout, J∆I, Scout, …) that wants to talk to a running
fai serve.
Status (2026-05-05): scaffold. Public surface (
HubClient,HubEndpoint) is committed; generated proto bindings land in a follow-up commit once the codegen step is wired in. Until then, downstream apps can compile against the stub and Studio uses mock data.
Why a separate SDK package
The platform hub speaks gRPC. Each Dart consumer (Studio plus each Tier-3 domain app) would otherwise re-generate proto bindings independently and write near-identical client boilerplate. This package centralises that work:
- One source of generated proto bindings.
- One typed
HubClientwrapper with helpers. - One place to bump when the wire protocol evolves.
Layout
fai_dart_sdk/
├── lib/
│ ├── fai_dart_sdk.dart # Public API
│ └── src/
│ ├── hub_client.dart # Typed client wrapper
│ └── generated/ # protoc output (committed; pinned to platform tag)
├── tools/
│ └── generate.sh # Wraps `protoc --dart_out=...` against ../fai_platform/proto
├── example/
└── pubspec.yaml
Repo placement
Will be published as fai/dart-sdk on Forgejo
(git.flemming.ws). The local directory fai_dart_sdk/
follows the established fai_platform/ layout convention.
Versioning
Tracks the platform's wire-protocol version, not the platform
binary version. As long as fai:platform@1.x is current, this
SDK stays at 0.x (will move to 1.0 once API stabilises);
when fai:platform@2.0 lands, a 2.x SDK ships in parallel
during the transition.