leonhard-s / dbg-census-cpp Goto Github PK

The build step is already uploading the installation into a directory. To support multi-config generators, we must place the different configuration target definitions side-by-side along with their respective binaries.

• Need to decide on a naming scheme to ensure that release and debug variants are distinct
• Alternatively (or in addition), we must place built binaries in subdirectories according to their build type

We should add some usage examples to showcase the library API and verify that its interfaces are convenient.

Unit-testing internal components such as HttpClientAdapter currently requires re-compiling and -linking the underlying source files to resolve the symbols.

While this project is small enough for compile times to not matter too much, it is still cleaner to do so through virtual targets for extensibility and reliability.

The URL generator is meant for development convenience/safety but has limited utility at runtime. As such, we should make sure that as little actual code is executed as possible.

Wonder if the interface could be reworked to be fully consteval-able.

Maybe a separate JoinBuilder would be best here.

Since we are already building ixWebSocket locally, it makes sense to use its HTTPS client along with the WebSocket one. If it proves incomvenient, no harm done. But it's always nice to get rid of some dependencies.

The retry policy currently only affects HTTP errors, but not Census error messages like {"error": "service_unavailable"}.

A basic builder for standard DBG Census URLs. This works with and returns plain C++ strings.

No assumptions about available query commands, endpoints, or collections are made to keep this compatible with third-party API mirrors such as Sanctuary.Census.

This project is not complex enough to warrant 4+ different libraries for its functionality, especially if client code decides to consume them as shared libraries.

Separating the REST and WebSocket clients is sensible as these two components could be used independently, but the URL generator should be redesigned to not require a hard library in the end; it is very basic anyway.

This also gives us more room to go to town with compile-time polymorphism and constexpr. Due to the dynamic nature of the query system we are unlikely to get complete compile-time evaluation, but it is an avenue worth exploring.

The current CI system stores both the build and install artifacts on every push, resulting in unneeded persistent storage usage.

Some ways to address this:

• Only retain build artifacts for 24 hours
• Only retain install artifacts for 7 days

This library is currently designed to be built statically only. Once utility libraries have been converted to header-only (see #5), it would be nice to have shared library support as well.

While this is an optional component that does not require any linking, there is no reason to model it as a separate install component or target. A different header is sufficient here.

These policies allow client code to control how bad payloads should be retried.

The reliance on the global VCPKG_INSTALLATION_ROOT environment variable requires users to make changes to the CMake presets (or add their own user preset) just to be able to build the solution.

vcpkg recommends using a git submodule, which should alleviate this issue.

The current client is designed to be agnostic to the JSON parser used. However, we may still want to further validate received responses as part of the retry check.

This project is meant to be consumed via CMake, so a simple export set and config file should do nicely. Since we have no transitive dependencies, no intermediate targets file should be required.

The ESS client currently takes raw JSON payloads for subscriptions. This should be expanded to generate them from scratch using the known event names and arguments.