Skip to content

Commit fa0c78b

Browse files
authored
Merge pull request #522 from minrk/clarify-dict-structure
clarify that the dict view of a message is not part of the versioned protocol
2 parents a2db4ef + 156d50b commit fa0c78b

File tree

1 file changed

+17
-5
lines changed

1 file changed

+17
-5
lines changed

docs/messaging.rst

Lines changed: 17 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -86,7 +86,7 @@ are reasonably representable in JSON.
8686
General Message Format
8787
======================
8888

89-
A message is defined by the following four-dictionary structure::
89+
A message can be represented as the following structure::
9090

9191
{
9292
# The message header contains a pair of unique identifiers for the
@@ -105,7 +105,7 @@ A message is defined by the following four-dictionary structure::
105105
'msg_type' : str,
106106
# the message protocol version
107107
'version' : '5.0',
108-
},
108+
},
109109

110110
# In a chain of messages, the header from the parent is copied so that
111111
# clients can track where messages come from.
@@ -123,6 +123,15 @@ A message is defined by the following four-dictionary structure::
123123
'buffers': list,
124124
}
125125

126+
.. note::
127+
128+
This dictionary structure is *not* part of the Jupyter protocol
129+
that must be implemented by kernels and frontends;
130+
that would be :ref:`wire_protocol`,
131+
which dictates how this information is serialized over the wire.
132+
Deserialization is up to the Kernel or frontend implementation,
133+
but a dict like this would be a logical choice in most contexts.
134+
126135
.. note::
127136

128137
The ``session`` id in a message header identifies a unique entity with state,
@@ -182,14 +191,17 @@ The Wire Protocol
182191
=================
183192

184193

185-
This message format exists at a high level,
194+
The above message format is only a logical representation of the contents of Jupyter messages,
186195
but does not describe the actual *implementation* at the wire level in zeromq.
187-
The canonical implementation of the message spec is our :class:`~jupyter_client.session.Session` class.
196+
This section describes the protocol that must be implemented by Jupyter kernels and clients
197+
talking to each other over zeromq.
198+
199+
The reference implementation of the message spec is our :class:`~jupyter_client.session.Session` class.
188200

189201
.. note::
190202

191203
This section should only be relevant to non-Python consumers of the protocol.
192-
Python consumers should simply import and the use implementation of the wire
204+
Python consumers should import and the use implementation of the wire
193205
protocol in :class:`jupyter_client.session.Session`.
194206

195207
Every message is serialized to a sequence of at least six blobs of bytes:

0 commit comments

Comments
 (0)