JuniperKernel (version 1.4.1.0)

doRequest: Handle Jupyter Requests

Description

Top-level Request Driver for R

Usage

doRequest(handler, request_msg)

Arguments

handler

An R method that handles the message type of request_msg. This function is passed in by the RequestServer, which handles all of generic message handling such as validation and routing. This handler is one of c('kernel_info_request', 'execute_request', 'inspect_request', 'complete_request', 'history_request', 'is_complete_request', 'comm_info_request', 'comm_open', 'comm_close', 'comm_msg', 'shutdown_request').

request_msg

A list passed in from RequestServer representing the deserialized message JSON.

Value

A list having names msg_type and content. The msg_type is the reply type corresponding to the request_msg's message type. For example, a kernel_info_request message produces a list with msg_type=kernel_info_reply. The content field of this list is dictated by the Jupyter wire message protocol. Note that the full reply to a Jupyter client is managed by the RequestServer.

Details

All client requests are eventually funneled through this top-level request driver via the RequestServer. It is the job of the RequestServer to inspect messages and invoke doRequest with the appropriate handler. In other words, doRequest focuses purely on redirecting stdout/stderr and calling the handler. Message streams are detoured to a socketConnection hosted in the current thread and connected to by a separate thread polling on a ZMQ_STREAM socket. These details are all handled by the RequestServer, and all doRequest does is sink messages to the socket and perform cleanup. The port is passed as part of the request_msg, and is chosen randomly by the RequestServer.

Examples

Run this code
# NOT RUN {
  handler <- execute_request
  request_msg <- list(stream_out_port=54321, stream_err_port=54322, list(code="rnorm(1000)"))
  doRequest(handler, request_msg)
# }
# NOT RUN {
# }

Run the code above in your browser using DataCamp Workspace