1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
// SPDX-FileCopyrightText: OpenTalk GmbH <mail@opentalk.eu>
//
// SPDX-License-Identifier: EUPL-1.2
/*!
Types and traits for the OpenTalk API and signaling protocols.
This crate re-exports items from the crates where they are defined.
All of these types can be used directly by importing the crate where they
are defined directly. If many types are needed in a project, this crate
could be the easier starting point though, because it serves as an index of
which crates are available.
# Crate features
In order to allow efficient usage of the referenced items, this crate
defines a flag for each of them. In addition some meta features are
available that pull in a set of dependencies.
## Meta features
### Types meta features
* **types-all** -
Enables all features that depend on specific datatype crates, indirectly by
enabling the **api** and the **signaling-all** features.
* **api** -
Enables the **api-v1** feature.
* **signaling-all** -
Enables all the signaling datatypes feature for all signaling modules.
### Functionality meta features
* **backend** -
Should be enabled when implementing the server side of either a signaling module
or an the API. Enables:
* the **backend** feature of each types crate
* **diesel**
* **rand**
* **redis**
* **serde**
* **frontend** -
Should be enabled when implemting the client side of either a signaling module
or the API. Enables:
* the **frontend** feature of each types crate
* **serde**
## Type features
* **api-v1** -
Re-exports [`opentalk-types-api-v1`](https://docs.rs/opentalk-types-api-v1) crate as [`api::v1`].
* **signaling** -
Re-exports all content of the [`opentalk-types-signaling`](https://docs.rs/opentalk-types-signaling) crate in the [`signaling`] module.
## Functionality features
* **clap** -
Should be enabled when implementing command-line tooling that exposes the
types using [`clap`](https://docs.rs/clap). This allows listing the possible
values of enumeration types using the builtin `--help` functionality of `clap`.
* **diesel** -
Enabling this feature makes some newtypes storable in a database through the
[`diesel`](https://docs.rs/diesel) crate. Used for implementing the server
side with a `diesel` database backend.
* **rand** -
Adds random generation of some datatypes such as `uuid`, so that they can
be generated on the server side in the API endpoint implementation or inside
signaling modules.
* **redis** -
Adds annotations to some signaling data types so that they can be stored
inside redis by the server side of a signaling module.
* **serde** -
Adds [`serde`](https://docs.rs/serde/) `Serialize` and `Deserialize`
implementations for each datatype that is sent over the network.
* **utoipa** -
Adds [`utoipa`](https://docs.rs/utoipa/) `ToSchema` and `IntoParams`
implementations to all types that are exposed in the OpenTalk Web API, so that
they can be used to generate an OpenAPI specification of the Web API.
*/
pub use opentalk_types_common as common;