some clarifications
This commit is contained in:
parent
b7da30d741
commit
0b94256b9d
@ -1,24 +1,27 @@
|
|||||||
//! Event management and forwarding
|
//! Event management and forwarding
|
||||||
//!
|
//!
|
||||||
//! This module provides components to perform event routing. The most important component for this
|
//! This module provides components to perform event routing. The most important component for this
|
||||||
//! task is the [EventManager]. It has a map of event listeners and uses a dynamic [EventReceiver]
|
//! task is the [EventManager]. It uses a map of event listeners and uses a dynamic [EventReceiver]
|
||||||
//! instance to receive all events and then route them to event subscribers where appropriate.
|
//! instance to receive all events and then route them to event subscribers where appropriate.
|
||||||
//!
|
//!
|
||||||
//! One common use case for satellite systems is to offer a light-weight publish-subscribe mechanism
|
//! One common use case for satellite systems is to offer a light-weight publish-subscribe mechanism
|
||||||
//! and IPC mechanism for software and hardware events which are also packaged as telemetry.
|
//! and IPC mechanism for software and hardware events which are also packaged as telemetry or can
|
||||||
//! This can be done with the [EventManager] like this:
|
//! trigger a system response. This can be done with the [EventManager] like this:
|
||||||
//!
|
//!
|
||||||
//! 1. Provide a concrete [SendEventProvider] implementation and a concrete [EventReceiver]
|
//! 1. Provide a concrete [SendEventProvider] implementation and a concrete [EventReceiver]
|
||||||
//! implementation. These abstraction allow to use different message queue backends.
|
//! implementation. These abstraction allow to use different message queue backends.
|
||||||
//! A straightforward implementation where dynamic memory allocation is not a big concern could
|
//! A straightforward implementation where dynamic memory allocation is not a big concern could
|
||||||
//! use [std::sync::mpsc::channel] to do this. It is recommended that these implementations
|
//! use [std::sync::mpsc::channel] to do this. It is recommended that these implementations
|
||||||
//! derive [Clone].
|
//! derive [Clone].
|
||||||
//! 2. Each event creator gets a sender component which allows it to send events to the manager.
|
//! 2. Each event creator gets a (cloned) sender component which allows it to send events to the
|
||||||
//! 3. The event manager receives all receiver ends so all events are routed to the
|
|
||||||
//! manager.
|
//! manager.
|
||||||
//! 4. Each event receiver and/or subscriber gets a receiver component. The sender component is
|
//! 3. The event manager receives the receiver component so all events are routed to the
|
||||||
//! used with the [SendEventProvider] trait and the subscription API provided by the
|
//! manager.
|
||||||
//! [EventManager] to subscribe for individual events, whole group of events or all events
|
//! 4. Additional channels are created for each event receiver and/or subscriber.
|
||||||
|
//! The sender component is used with the [SendEventProvider] trait and the subscription API
|
||||||
|
//! provided by the [EventManager] to subscribe for individual events, whole group of events or
|
||||||
|
//! all events. The receiver/subscribers can then receive all subscribed events via the receiver
|
||||||
|
//! end.
|
||||||
//!
|
//!
|
||||||
//! Some components like a PUS Event Service or PUS Event Action Service might require all
|
//! Some components like a PUS Event Service or PUS Event Action Service might require all
|
||||||
//! events to package them as telemetry or start actions where applicable.
|
//! events to package them as telemetry or start actions where applicable.
|
||||||
|
Loading…
Reference in New Issue
Block a user