dora-image-view

32 Commits 5 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
cristhian	344a527097	record that the webcam example is verified, and pin v0.1.1 The example carried a caveat saying it validated but could not be run, because a `git:` node could not be fetched. The organization is public now, so it can: dora clones dora-webcam at the pinned tag, builds both nodes, and runs them against a real camera to a clean exit. The pin moves to v0.1.1, whose documentation shows the https URL. v0.1.0 points at an ssh:// URL that dora cannot authenticate, so anyone copying the wiring out of that tag would have hit the failure this example exists to demonstrate the absence of. What a `git:` node does require is still recorded, since it is not obvious: anonymous read, which on Gitea means a public organization and not merely a public repository.	2026-09-15 06:50:43 -03:00
cristhian	f7171de2af	fetch git nodes over https validate / validate (pull_request) Successful in 59m10s Details ssh:// cannot authenticate under dora-cli 1.0.1: it fetches through libgit2 with no credential callback, so the only transport that can work is anonymous https. The documented URLs move accordingly, and the repository is now dora-image-view rather than dora-plot. The note about what a `git:` node needs is corrected while here. The cause is not that a repository is private but that the fetch is anonymous: on Gitea a repository inside a private organization is internal and answers an anonymous clone with 401 even when the repository itself is marked public. The organization has to be public too.	2026-09-15 06:29:37 -03:00
cristhian	15e0b9155a	add a worked example wiring dora-webcam into this node The only dataflow here drove the viewer from a test fixture, so nothing showed how to consume a real producer. dataflow_webcam.yml wires dora-webcam v0.1.0 into it: the camera publishes std/media/v1/Image and this node draws it, with depth, camera_info, text and bbox simply unwired, which is what every input being optional buys. The dependency points one way only. A consumer naming its producer is an arrow; dora-webcam names no consumer, so there is no cycle. Two things are deliberate. The camera's output type is repeated in the dataflow because a `git:` node's manifest is not read at validate time, only at build, so without it the two contracts are never compared -- a deliberate mismatch is caught with the annotation and passes silently without it. And the file carries no strict_types: a camera publishes an image and nothing else, and strict validation warns about every typed input a dataflow leaves unwired. Interoperability was verified directly, feeding dora-webcam's packed payload into this node's decoder across bgr8, rgb8, jpeg, png and yuv420: the struct types are identical and the lossless encodings round-trip exactly. The dataflow validates but was not run: with dora-cli 1.0.1 a `git:` node pointing at a private repository does not build over either transport, which the file and the README record.	2026-09-15 06:26:10 -03:00

Author

SHA1

Message

Date

cristhian

344a527097

record that the webcam example is verified, and pin v0.1.1

The example carried a caveat saying it validated but could not be run, because
a `git:` node could not be fetched. The organization is public now, so it can:
dora clones dora-webcam at the pinned tag, builds both nodes, and runs them
against a real camera to a clean exit.

The pin moves to v0.1.1, whose documentation shows the https URL. v0.1.0 points
at an ssh:// URL that dora cannot authenticate, so anyone copying the wiring out
of that tag would have hit the failure this example exists to demonstrate the
absence of.

What a `git:` node does require is still recorded, since it is not obvious:
anonymous read, which on Gitea means a public organization and not merely a
public repository.

2026-09-15 06:50:43 -03:00

cristhian

f7171de2af

fetch git nodes over https

validate / validate (pull_request) Successful in 59m10s

Details

ssh:// cannot authenticate under dora-cli 1.0.1: it fetches through libgit2
with no credential callback, so the only transport that can work is anonymous
https. The documented URLs move accordingly, and the repository is now
dora-image-view rather than dora-plot.

The note about what a `git:` node needs is corrected while here. The cause is
not that a repository is private but that the fetch is anonymous: on Gitea a
repository inside a private organization is internal and answers an anonymous
clone with 401 even when the repository itself is marked public. The
organization has to be public too.

2026-09-15 06:29:37 -03:00

cristhian

15e0b9155a

add a worked example wiring dora-webcam into this node

The only dataflow here drove the viewer from a test fixture, so nothing showed
how to consume a real producer. dataflow_webcam.yml wires dora-webcam v0.1.0
into it: the camera publishes std/media/v1/Image and this node draws it, with
depth, camera_info, text and bbox simply unwired, which is what every input
being optional buys.

The dependency points one way only. A consumer naming its producer is an arrow;
dora-webcam names no consumer, so there is no cycle.

Two things are deliberate. The camera's output type is repeated in the dataflow
because a `git:` node's manifest is not read at validate time, only at build, so
without it the two contracts are never compared -- a deliberate mismatch is
caught with the annotation and passes silently without it. And the file carries
no strict_types: a camera publishes an image and nothing else, and strict
validation warns about every typed input a dataflow leaves unwired.

Interoperability was verified directly, feeding dora-webcam's packed payload
into this node's decoder across bgr8, rgb8, jpeg, png and yuv420: the struct
types are identical and the lossless encodings round-trip exactly.

The dataflow validates but was not run: with dora-cli 1.0.1 a `git:` node
pointing at a private repository does not build over either transport, which
the file and the README record.

2026-09-15 06:26:10 -03:00