Why not use OpenAPI?

[DanielHabenicht]

Do I miss something or are there only types defined inside the core library?

Using OpenAPI or just JSONSchema would allow the following benefits:

• Clear understanding of what is specified (Python could be used for literally anything, but JSONSchema just for defining the interfaces
• Types can be automatically generated in any language
• (if OpenAPI) Routes and requests can be specified and automatically generated for any language you might want to implement a checker.

[Savallator]

The Interfaces and API is defined here.

[domenukk]

Having the spec as markdown in an implementation repository is not really an ideal solution.
I agree that using OpenAPI could be really cool and useful.

[DanielHabenicht]

Ok, will put a PR against EnoEngine then, with a first draftspec.

[DanielHabenicht]

I would add an OpenAPI Spec for EnoChecker, but for the Engine it would be better to generate it from you project via swashbuckle, I can add it too if you want.

[domenukk]

If it's generated from the code, it's no longer an actual independent specification, right? It would make the code the specification, instead (which would be fine by me, too, just pointing it out)

[DanielHabenicht]

yes, but as the engine is your single source of truth either way it makes sense?

[DanielHabenicht]

For the dashboard there is no API, right? EnoEngine is just sharing the file via a shared docker volume?

[Trolldemorted]

EnoEngine is not running within docker, so it just puts the scoreboard files into ../data, which is /services/data/ in the bambictf setup.

These files are sent to the EnoLandingPage's bind-mounted input folder with rsync in a while true loop. A bit hacky, but it works :)

[DanielHabenicht]

Might be good to add an architectural overview :D

[Trolldemorted]

I agree, do you have an idea how one can nicely visualize the information flow within distributed systems?

The mini-picture on the slides was created o draw.io, but everything I create there looks hideous.

[DanielHabenicht]

For starters maybe: https://mermaid-js.github.io/mermaid/#/flowchart ?
You can also integrate it in https://github.com/enowars/enochecker/tree/main/docs with https://pypi.org/project/sphinxcontrib-mermaid/

[DanielHabenicht]

So before going ahead I would appreciate your feedback:

1. Do you want to specify the openapi spec for the checker first (and then build any checker implementation from there) or do you want to build a reference checker and generate the spec from it (e.g. using the EnoChecker)?
2. For the python checker we could than use connexion (Flask based as the current one) to implement a Spec Validated checker.

BTW: Is there a reason why async and sync enochecker are not sharing a codebase?

[DanielHabenicht]

Here a first preview:
https://danielhabenicht.stoplight.io/docs/enochecker/

Any preferences for a documentation generator? I would go for https://mrin9.github.io/RapiDoc/examples/themes.html#post-/pet