txtxtxtx/tx_di

1. This repository is a Rust workspace centered on a dependency injection framework called tx_di. The architecture is split into three layers: a macro crate that records component metadata at compile time, a core runtime that builds and resolves components, and a set of plugins/examples that show how the framework is embedded into real systems.

2. The framework’s main boundary is between compile time and runtime. tx-di-macros expands #[tx_comp], #[tx_cst], and related attributes into component descriptors, dependency lists, scope metadata, and default init hooks. Those generated items are registered into linkme distributed slices so the runtime does not need reflection or filesystem scanning.

3. tx-di-core is the runtime engine. It owns the component registry, configuration loading, dependency graph resolution, and injection APIs. The key runtime flow is: collect metadata from linkme, load global TOML config if present, topologically sort components with Kahn’s algorithm, build singleton/prototype instances into a DashMap, then expose them through BuildContext and the immutable App snapshot.

4. The DI model is intentionally store-based. Components are stored as Arc-wrapped values or factories keyed by type identity, and injection is done by type lookup rather than name lookup. This means the primary data flow is from typed metadata to typed instances, with scope decisions handled by the framework rather than by consumers.

5. Configuration is a first-class input to the runtime. Components marked as conf are deserialized from TOML sections, and the global AppAllConfig object gives access to raw configuration values. In architecture diagrams, config should be shown as an external source feeding BuildContext before component construction begins.

6. tx-di-macros and tx-di-core are tightly coupled but separate by responsibility: macros generate the static description of a component, while core executes the graph. That separation is important because it is what enables compile-time collection with runtime-only resolution, while keeping component authors on a simple attribute-based API.

7. plugins/ contains reusable integrations built on top of the core DI model. These are not just utilities; they are injectable subsystems that become part of the dependency graph through the same linkme registration mechanism. The important plugins are tx_di_log for tracing-based logging, tx_di_axum for HTTP hosting, tx_di_sip for SIP transport and routing, tx_di_gb28181 for GB28181 server behavior, tx_di_gb28181_client for device emulation, tx_di_can for CAN/CANFD communication, and small support crates such as tx_di_toasty.

8. tx_di_axum is the web boundary. It wraps an Axum/Tokio server and exposes HTTP concerns such as health checks, CORS, static files, and middleware. In the architecture, it sits at the edge, consuming DI-managed config and services, then serving requests into the rest of the application.

9. tx_di_sip is the protocol boundary for SIP. It provides the transport/listener and message routing layer that the GB28181 plugins build upon. Architecturally, it turns network SIP traffic into handler dispatch, and it is the bridge between raw UDP/TCP packets and higher-level domain logic.

10. tx_di_gb28181 and common/tx_gb28181 form the main domain subsystem for GB28181-2022. The common crate holds shared protocol types and parsers/encoders for SIP, SDP, XML, device/channel models, and events. The server plugin adds registration, catalog queries, INVITE/playback flows, PTZ control, alarms, and media backend integration. The client plugin simulates a device side of the same protocol. The shared library is the contract boundary between both sides.

11. Media handling in the GB28181 server is separated from signaling. Under plugins/tx_di_gb28181/src/media, the code abstracts different streaming backends such as ZLMediaKit, MediaMTX, or a null backend. This means signaling logic can request media resources without being coupled to a specific streaming server implementation.

12. tx_di_can is a distinct embedded/diagnostics subsystem. It abstracts CAN and CANFD adapters, ISO-TP segmentation, UDS diagnostic messaging, and flash/programming workflows. Unlike the web/SIP pieces, this plugin represents a hardware-protocol edge that can also be injected and wired through the same DI mechanism.

13. The examples/ directory shows two end-to-end applications built from the same primitives. gb28181_admin combines a backend API and Vue UI for administration, sessions, devices, and SSE updates. gb_cams models a camera fleet with device management, event APIs, and a web UI. These examples are important because they show how the framework is intended to assemble into complete systems.

14. Overall, the architecture is: component definitions in user crates and plugins → compile-time metadata generation via proc macros → link-time registration via linkme → runtime graph construction and configuration loading in tx-di-core → edge services such as Axum, SIP, GB28181, or CAN consuming the injected components. This is the main shape to capture in a diagram.