You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
don't create new client-to-server messages based on return value
7
+
sometimes different api client functions might be needed, but the same messages should be used
8
+
9
+
distinguish based on sent information, so that messages can be handled by server quickly and easily
10
+
_with_streams would not be strictly necessary, but it increases performance if the server does not have to find out
11
+
if any of the arguments are streams and need to be handles differently
12
+
13
+
tldr:
14
+
make client-to-server and server-to-client messages orthogonal
15
+
16
+
# Client to server, no response, errors are ignored silently
17
+
18
+
NOTIFY:
19
+
function call
20
+
21
+
NOTIFYMETHOD
22
+
method call on OBJECT
23
+
24
+
NOTIFYMETHOD_BY_RESULT
25
+
method call on OBJECT, referred to by RESULT
26
+
27
+
*_WITH_STREAMS # not implemented for all methods yet
28
+
arguments can contain `Streamables`
29
+
separate messages for performance reasons
30
+
could be implemented as another parameter in request. eg.
31
+
client could send 0, 1, 2:
32
+
0: auto, server has to figure out if streams are included
33
+
1: client says there are no streams
34
+
2: client says there are streams
35
+
actually 0 is not neccessary as the work done would be the same as 2. "no streams" is just a performance optimisation
36
+
37
+
# Client to server, return values are
38
+
- RESULT, OBJECT, ERROR
39
+
- STREAM_RESULT, STREAM_END, STREAM_ERROR
40
+
41
+
CALL
42
+
function call
43
+
44
+
CALLMETHOD
45
+
method call on OBJECT
46
+
47
+
CALLMETHOD_BY_RESULT
48
+
method call on OBJECT, referred to by RESULT
49
+
50
+
*_WITH_STREAMS # not implemented for all methods yet
51
+
arguments can contain `Streamables`
52
+
separate messages for performance reasons
53
+
54
+
# Client to server, no response, errors are ignored silently
55
+
56
+
DELINSTANCE # should be DELOBJECT for symmetry?
57
+
deletes remote OBJECT
58
+
59
+
DELINSTANCE_BY_RESULT
60
+
deletes remote OBJECT, referred to by RESULT
61
+
62
+
# Client to server, streams, only indirectly user initiated
63
+
64
+
STREAM_ARGUMENT
65
+
used with the *_WITH_STREAMS messages to deliver data
66
+
67
+
ARGUMENT_ERROR
68
+
used with the *_WITH_STREAMS messages to signal errors
69
+
70
+
ARGUMENT_END
71
+
used with the *_WITH_STREAMS messages to mark the end of a stream
72
+
73
+
# Server to client
74
+
75
+
RESULT
76
+
normal value, i.e. no `ObjectId` or `GeneratorType` which are handled separately
77
+
can send *METHOD_BY_RESULT messages using this return type
78
+
79
+
OBJECT
80
+
object instance
81
+
can send *METHOD messages using this return type
82
+
83
+
ERROR
84
+
signals an error, possible errors are
85
+
- GeneralError
86
+
- NoSuchFunction
87
+
- WrongArguments
88
+
- UserError
89
+
- NoService
90
+
- Deferred
91
+
- InvalidObject
92
+
- ResourceExhausted
93
+
94
+
# Server to client, streams, only indirectly user initiated
95
+
96
+
STREAM_RESULT
97
+
stream value, basically an iterable result
98
+
99
+
STREAM_ERROR
100
+
signals error during stream
101
+
102
+
STREAM_END
103
+
marks the end of a stream
104
+
105
+
# Notes
106
+
"STREAM" messages are not needed, but the client needs to call special `_stream*` functions on the library so the returned STREAM_* messages can be handles correctly
0 commit comments