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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
//! Typed topics - the api-local builder output (D61), side-branded for L1 (plan #00).
//!
//! A [`Topic`] is a version-qualified topic key plus a phantom [`TopicKind`]
//! that ties the key to its body type(s) **and to the side** the holder may
//! take. The api tree's `topic` builders return these; the `SetupContext` handle
//! builders consume them. The wire body never appears in the key, but the
//! version does - the key is `v0.1/drive/state`, not `drive/state` (D62/D1):
//! folding the version into the key is what makes different versioned names
//! physically distinct Zenoh keys.
//!
//! # Side branding (L1)
//!
//! The kind marker is the compile-time gate that makes taking the **wrong side**
//! of a topic a type error. The four markers split each wire shape by side:
//!
//! - [`Publish<B>`] - the participant *publishes* `B` (a client sending a command,
//! or an owner publishing its state).
//! - [`Subscribe<B>`] - the participant *subscribes/observes* `B` (a client
//! observing state, or an owner reading its command input).
//! - [`AskQuery<Req, Resp>`] - the **client** side of a query: it *calls* the owner.
//! - [`ServeQuery<Req, Resp>`] - the **owner** side of a query: it *serves* requests.
//!
//! The brand is a COMPILE-TIME marker only: the underlying key and the actual
//! `Publisher`/`Subscriber`/`Latest`/`Querier`/server ops are unchanged. The api
//! tree emits the builder tree twice - a public *client* builder and an
//! `internal` *owner* builder over identical keys - so the side a participant gets
//! is decided by which builder it calls, and a wrong side fails to compile in the
//! `SetupContext` handle builder that consumes the `Topic`.
use Cow;
use PhantomData;
/// A pub/sub topic the participant **publishes** `B` on (client command, or owner
/// state). The publish side of the former side-agnostic `PubSub<B>`.
>);
/// A pub/sub topic the participant **subscribes/observes** `B` on (client
/// observing state, or owner reading its command input). The subscribe side of
/// the former side-agnostic `PubSub<B>`.
>);
/// The **client** side of a query topic carrying request `Req`/response `Resp`:
/// the holder *calls* the owner. The caller side of the former side-agnostic
/// `Query<Req, Resp>`.
>);
/// The **owner** side of a query topic carrying request `Req`/response `Resp`:
/// the holder *serves* requests. The server side of the former side-agnostic
/// `Query<Req, Resp>`.
>);
/// Marker for the kind (wire shape + side) of a [`Topic`]. Sealed.
/// A typed topic: a version-qualified key bound to its body type(s) via `Kind`.
/// Attempted to publish on a wildcard (subscribe-only) topic.