Don't recall any basic "project infrastructure" discussions happening
yet for the upcoming replacement/alternative for ZeekControl that we
want to introduce in Zeek 3.2 (roadmap/design links found at ), so
here's starting questions.
# What to Name It ?
Suggestion: `zeekcl`, Zeek (Command-Line) CLlient.
Open to ideas, but will use `zeekcl` below.
# What Programming Language ?
`zeekcl` has different/narrower scope than ZeekControl. It's more
clearly a "client" with sole job of handling requests/responses via
Broker without many (any?) system-level operations/integrations.
Meaning there may be less of an approachability/convenience gap
between C++ versus Python with `zeekcl` than there was with
Also nice if `zeekcl` doesn't require more dependencies beyond what
`zeek` needs since they're expected to be used together.
Is use of Python still desirable for other reasons? Otherwise, I lean
towards `zeekcl` being C++.
For reference/sanity-check in terms of what people expect `zeekcl` to
be: in my testing of the SupervisorControl framework , I had a
sloppy Zeek script implementing the full "client side" (essentially
the majority of what `zeekcl` will do) in ~100 LOC. Most operations
are that simple: send request and display response.
That does mean the third option to consider besides either Python or
C++ is Zeek's scripting language (e.g. `ctl.zeek`), but I don't
suggest that since (1) using a full `zeek` process is way more than we
need and (2) the command-line interface is awkward (`zeek ctl
Supervisor::cmd="status"` versus `zeekcl status`)
# Where's the Source Code Live ?
Past experiences with ZeekControl being in a separate repo than Zeek
are negative in terms of CI/testing: changes in Zeek have broken
ZeekControl, but go uncaught for a while since it is tested
Since common use/maintenance will involve both `zeek` and `zeekcl`,
and also don't expect the later to accrue large amounts of code
deserving of a separate project, I plan to have `zeekcl` code/tests
live inside the main Zeek repo.