RFC: Application Interface Strategy (Library vs. Standalone Binary)
Context & Objective
We need to determine the primary distribution and integration method for our runtime verification engine.
We are evaluating two primary approaches: distributing the engine as a C++ Library, or as a compilable Standalone Binary Executable.
Detailed Proposals
Option 1: C++ Library (API Integration)
Description: We provide the engine as a C++ library. Users include our headers and link the library against their target C++ application, feeding input data and the formulas directly into the monitors via API calls (e.g., monitor.evaluate()).
- Pros:
- Deep Integration: Allows the target application to react programmatically to verification failures (e.g., triggering a safe-mode or logging a custom stack trace) immediately when a rule is violated.
- Cons:
- Language Lock-in: The target application must be written in C++ (or capable of FFI/C-bindings).
- Integration Friction: Requires the user to modify their source code and update their build system (e.g., CMake) to link our library.
- Harder to Benchmark: The main premise of this project is performance optimization, making rigorous benchmarking critical. Most existing tools (like Reelay) evaluate performance via offline monitoring. Benchmarking an in-memory library against a file-based offline tool introduces variables (like the target application's own execution overhead) that make apples-to-apples comparisons highly difficult.
Option 2: Standalone Binary Executable (CLI Tool)
Description: We compile the engine into a standalone executable. Users do not modify their application code. Instead, their application outputs trace logs (e.g., JSON, or a custom binary format) to a file. The user then runs our binary from the command line, passing the trace file and the specification file as arguments.
- Pros:
- Language Agnostic: Can verify traces generated by systems written in Python, Java, Rust, or any other language, provided they format the output correctly.
- Zero Code Modification: Excellent for "Offline Monitoring." Users can analyze historical logs without touching their application's architecture or build system.
- Easier to Benchmark (Apples-to-Apples): Because we are reading from a standardized trace file, we can feed the exact same input dataset to our tool, Reelay, and other competitors. This isolates the verification engine's pure execution time, giving us clean, reproducible metrics for our academic results.
- Cons:
- Delayed Feedback: Errors are only caught after the fact, making it impossible for the target system to react to a failure at runtime. Piped inputs (e.g.,
stdout | monitor) can mitigate this, but IPC (Inter-Process Communication) still introduces significant overhead compared to direct memory access.
Author's Recommendation
I recommend prioritizing the Standalone Binary (Option 2) for our initial implementation.
Since the primary academic value of this senior project lies in proving our performance optimizations, establishing a clean and irrefutable benchmarking pipeline against existing tools like Reelay is our top priority. The standalone approach makes this trivial.
Once the core data-oriented architecture is proven and benchmarked offline, we can easily strip away the file I/O layer and expose the core engine as a C++ library in a future milestone.
RFC: Application Interface Strategy (Library vs. Standalone Binary)
Context & Objective
We need to determine the primary distribution and integration method for our runtime verification engine.
We are evaluating two primary approaches: distributing the engine as a C++ Library, or as a compilable Standalone Binary Executable.
Detailed Proposals
Option 1: C++ Library (API Integration)
Description: We provide the engine as a C++ library. Users include our headers and link the library against their target C++ application, feeding input data and the formulas directly into the monitors via API calls (e.g.,
monitor.evaluate()).Option 2: Standalone Binary Executable (CLI Tool)
Description: We compile the engine into a standalone executable. Users do not modify their application code. Instead, their application outputs trace logs (e.g., JSON, or a custom binary format) to a file. The user then runs our binary from the command line, passing the trace file and the specification file as arguments.
stdout | monitor) can mitigate this, but IPC (Inter-Process Communication) still introduces significant overhead compared to direct memory access.Author's Recommendation
I recommend prioritizing the Standalone Binary (Option 2) for our initial implementation.
Since the primary academic value of this senior project lies in proving our performance optimizations, establishing a clean and irrefutable benchmarking pipeline against existing tools like Reelay is our top priority. The standalone approach makes this trivial.
Once the core data-oriented architecture is proven and benchmarked offline, we can easily strip away the file I/O layer and expose the core engine as a C++ library in a future milestone.