-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathPROTOCOL
68 lines (53 loc) · 2.6 KB
/
PROTOCOL
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
This file describes the EVENT protocol (EvP),
a generic events dispatching protocol
This protocol can be server on a UNIX stream socket or a TCP connection.
When using TCP, the connection *must* use TLS.
Messages are UTF-8 text which ends at the "\n" character.
Messages starting with a dot (".") are multiple-lines messages and ends with a
single dot on its own line (".\n"). They are referred as "dot messages".
Any error in the pairing should close the connection. Implementations should
send a "BYE Wrong dot message" message in this case.
An implementation must discard unknown messages for compatibility.
Only dot messages require special handling regarding that: an implementation
must match any dot message with its corresponding ending line (".\n") and
ignore it. Nesting is possible and must be handled.
If the first received message is a valid HTTP request (so "GET / HTTP/1.1\r"),
the implementation should either handle it as EvP over WebSocket or send
an 501 status (so "HTTP/1.1 501 Not Implemented\r\n\r\n") and close the
connection.
Event related messages
----------------------
.EVENT <id> <category> <name>
Inform the server that an event happened
The id is a UUID.
The name must contain only the characters
"A-Za-z0-9-." (without the quotes).
The category can use the same characters as the name.
Special categories may exist, beginning by a dot ('.').
These special events are generated by action endpoints,
for example to indicate user action.
These special events *must* be forwarded to all connected clients.
The message may contain data using the corresponding messages.
DATA <name> <content>
These messages are nested in .EVENT messages.
The data name has the same constraints as event category and name.
The data content is a GVariant text.
See https://developer.gnome.org/glib/stable/gvariant-text.html
for more information.
Connection related messages
---------------------------
SUBSCRIBE [<category>]
.SUBSCRIBE
Ask the server to send us events.
The first form ask for either all events or a single category.
The second form ask for any number of categories (but at least two).
Must be sent only once.
PING
Both server and client can send this message as a probe at any time
to keep the connection alive. No answer is required.
BYE [<reason>]
Close the connection.
The connection is closed immediately and must not be used any more.
The reason is an human readable reason possibly shown to the user.
The reason is optional, thus implementations must check for the exact
"BYE" message as well as the "BYE " prefix.