This would allow Annotators to depend on Annotations without knowing
how they were created.
However, keeping track of these generic Annotations (GAnns) is hard:
- When another Annotator runs and returns a GAnn, do we replace it?
Alternatively, should multiple Annotators be allowed to return the
same GAnn?
- If an Annotator previously returned a GAnn but not when being
re-run, do we drop the GAnn?
- Should we keep track of which Annotator created which GAnn? If so,
how and what granularity?
Annotators may want to match vertices based on partial information.
Especially, with split visualisation.ospf, we want to be able to match
for networks even without the full details (like DRs or all the
current prefixes.)
This finally uses the VertexFinder :-) Also, it is definitely not a
dataclass, who wrote that? ;-)
This script serves as a simple demonstration of how to use birdvisu.
Over time, it should become shorter, as more of its features are
integrated into birdvisu itself, until at last it becomes only a very
thin wrapper.
The functionality will probably be incorporated into some core /
orchestrator birdvisu module, but there is no such thing yet.
The clarifications sometimes are about change that will come in a future
commit, sorry for that. (But the order of commits on this branch is
broken anyway…)
At this moment it no actual providers are present, but the parsing of
ospffile is the bigger part of providing topologies.
Maybe this file is not the good place for that code.
This is a trivial intro message, just to make sure docs can be written
and built.
May serve as a reference commit on how to add new pages to
documentation.