#112 has marked the end of the PoC phase of Quent by demonstrating we can define composable and reusable application event models from single & relatively straightforward definitions from which an enormous amount of boilerplatey code can be generated to tie everything from instrumentation library all the way to analysis and UI together.
The current PoC-grade implementation has quite a lot of tech debt that needs to be erased in order to stabilize the project and provide a solid foundation for both users and a next wave of features. To this end, #128 has dissected the entire project into somewhat atomic parts, and provides a proposal for a more solid foundation.
This is a tracking issue for migrating the project to that architecture. The end result will be a first beta release (v0.1).
The plan is to introduce (or refactor) the following crates in this order:
This tracking issue ends there, as this provides everything necessary to retain all currently existing functionality, and will stabilize everything on the data capture side, such that historical data produced by early adopters is less likely to become unusable by future versions (although I think it is too early to conclude we could perhaps never have breaking changes to the data model).
These changes will incorporate solutions for the following pre-existing issues:
#112 has marked the end of the PoC phase of Quent by demonstrating we can define composable and reusable application event models from single & relatively straightforward definitions from which an enormous amount of boilerplatey code can be generated to tie everything from instrumentation library all the way to analysis and UI together.
The current PoC-grade implementation has quite a lot of tech debt that needs to be erased in order to stabilize the project and provide a solid foundation for both users and a next wave of features. To this end, #128 has dissected the entire project into somewhat atomic parts, and provides a proposal for a more solid foundation.
This is a tracking issue for migrating the project to that architecture. The end result will be a first beta release (v0.1).
The plan is to introduce (or refactor) the following crates in this order:
1.quent-schema: captures the structure of application event model data and introduces the concept of opaque constraints that can be implemented by any built-in or third-party crates to constrain events to arbitrary conventions.2.quent-constraints: constraints trait and canonical validation path for schemas (dep 1)3.quent-fsm: built-in constraint where events represent FSM transitions and must be sequenced to follow a well-defined topology (dep 1, 2)4.quent-ref-<x>: built-in constraint for entity refs, so they can be given semantically enriched data-carrying roles and constraints (dep 1, 2)quent-ref-target: feat: add ref-target constraint crate #199quent-ref-tree: feat: add ref-tree constraint crate #2005.quent-instrumentation-<X>: Generic instrumentation library traits and implsquent-instrumentation-build: Generates instrumentation libs from schemaquent-instrumentation-runtime: Generic types for any instrumentation lib + migrating PoC crates to the new arch:6.quent-model: Rust modeling API + macros to produce instrumentation lib + schemas in build.rs (dep 1, 2, 3, 4, 5)7.quent-cpp: Codegen for C++ targets (dep 1)8.quent-python: Codegen for Python targets (dep 1)9.quent-resource: opt-in constraint + modeling convenience macro for resources and usages of those resources in FSM states (dep 1, 2)This tracking issue ends there, as this provides everything necessary to retain all currently existing functionality, and will stabilize everything on the data capture side, such that historical data produced by early adopters is less likely to become unusable by future versions (although I think it is too early to conclude we could perhaps never have breaking changes to the data model).
These changes will incorporate solutions for the following pre-existing issues: