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
//! What a stream payload has to be able to become on the wire.
//!
//! # Why this exists
//!
//! Because "the payload is a JSON value" stopped being true when `2024-11-05`
//! arrived. On Streamable HTTP every frame is a `message` event and every
//! payload is JSON, so `EventTail<Value>` and a `Borrow<Value>` bound said
//! everything there was to say. The legacy transport sends one frame that is
//! **not** JSON: the `endpoint` event, whose data is a bare URI.
//!
//! A URI is not JSON. Wrapping it as `Value::String` would put quotes in the
//! data — `data: "/messages?sessionId=x"` — and a client doing what the
//! specification says to do with the event, hand that to a URL parser and fail.
//! The real servers write the bare URI, and so does this crate.
//!
//! # Why the trait is here and not in `domain/`
//!
//! Because it is an SSE question, not a domain one: it answers "how does this
//! payload become a frame", and the answer is a field name, an id, and a
//! serialisation. `EventName` and `SseEvent` are in this tree for the same
//! reason. A domain that knew about `event:` would be a domain modelling a
//! wire format, which is the thing the layering exists to prevent.
//!
//! # Why it is fallible
//!
//! Because encoding can fail and a stream cannot: a payload with no JSON form
//! — a non-string map key — has no wire representation, and the honest answer
//! is a refusal rather than a frame that decodes to something else. That
//! refusal is the server's own bug, which is why the caller reports it as a
//! `500` and not as the client's fault.
use Value;
use crateEventId;
use ;
/// A payload an [`EventTail`](super::EventTail) can put on the wire.
///
/// The one method, because it is the only question the ring asks. The
/// alternative shape — a payload that *is* an [`SseEvent`] — was rejected
/// because it would push the id out to every call site, and the id is the
/// ring's business, not the payload's.
/// A JSON payload becomes a `message` event — unnamed, because Streamable
/// HTTP does not name its frames and a name here would be a `2026-07-28`
/// client's problem to have an unexpected field.