Packages

p

jupyter4s

protocol

package protocol

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. Protected

Package Members

  1. package messages

Type Members

  1. case class ConnectionInfo(username: String, session: String) extends Product with Serializable
  2. final case class Header(msgId: String, username: String, session: String, msgType: String, version: Option[String], date: Option[Instant]) extends Product with Serializable
  3. final case class KernelSpec(argv: List[String], displayName: String, language: String, interruptMode: Option[String] = None, env: Map[String, String] = Map.empty, metadata: Option[RawJson] = None) extends Product with Serializable

    Describes a Jupyter kernel and how to start it.

    Describes a Jupyter kernel and how to start it.

    See http://jupyter-client.readthedocs.io/en/5.2.3/kernels.html#kernel-specs

  4. final case class Message(identities: Option[List[String]], header: Header, parentHeader: OptionalHeader, metadata: Map[String, RawJson], content: RawJson, channel: Channel) extends Product with Serializable

    Defines a valid Jupyter message according to the Jupyter protocol specification v5.3.

    Defines a valid Jupyter message according to the Jupyter protocol specification v5.3. A valid Jupyter message looks like the following.

    { 'header' : { 'msg_id' : str, # typically UUID, must be unique per message 'username' : str, # typically user logged in the notebook interface 'session' : str, # typically UUID, should be unique per session 'date': str, # ISO 8601 timestamp for time message is created 'msg_type' : str, # valid message type strings, listed below. 'version' : '5.0' # message protocol version },

    # Inlined parent header for clients to track where messages come from 'parent_header' : dict,

    # Any metadata associated with the message 'metadata' : dict,

    # Must be a dict, actual content structure depends on the message type 'content' : dict,

    # optional: list of binary data buffers for supported binary extensions 'buffers': list, }

    When the message is sent through ZeroMQ, the actual wire message looks like the following:

    [ b'u-u-i-d', # zmq identity(ies) b'<IDS|MSG>', # delimiter b'baddad42', # HMAC signature b'{header}', # serialized header dict b'{parent_header}', # serialized parent header dict b'{metadata}', # serialized metadata dict b'{content}', # serialized content dict b'\xf0\x9f\x90\xb1' # extra raw data buffer(s) ... ]

    Note the addition of the following fields: ZeroMQ identities, delimiter, channel and the HMAC signature. Given that the delimiter and HMAC signature are used for validation and the channel only for routing purposes, our message structure below only adds the ZeroMQ identities to the standard Jupyter message description.

    The Jupyter protocol messaging specification is available https://jupyter-client.readthedocs.io/en/stable/messaging.html.

  5. abstract class MessageTemplate[RequestType <: String with Singleton, RequestStructure] extends AnyRef
  6. case class OptionalHeader extends Product with Serializable
  7. final case class Secret[T] extends Product with Serializable

Value Members

  1. object ConnectionInfo extends Serializable
  2. object Header extends Serializable
  3. object KernelSpec extends Serializable
  4. object Message extends Serializable
  5. object MessageTemplate
  6. object OptionalHeader extends Serializable
  7. object Protocol
  8. object Secret extends Serializable

Ungrouped