Cell Code Needs To Set HTTP Response Metadata

[Lull3rSkat3r]

Cell Code Needs To Set HTTP Response Metadata

[parente]

Another option that is more language agnostic but also more "magical" (in a bad way) ...

If the cell emits JSON, parse it. If it contains a "headers" key and a "body" key, use those to set the HTTP header and body appropriately. (Same for the "status" for issue #47).

Strawman here is to use a form of duck typing to do the detection, but maybe there's a more explicit way.

[parente]

Brainstorming:

• Use the different message types to separate print (body, output) vs execute result (implicit display) (pro: agnostic, con: multiple outputs can get confusing)
• Set a global RESPONSE variable before the cell ends with a JSON value contain headers, status, etc. (pro: consistent with REQUEST, con: more kernel comm)
  • We can clear RESPONSE after reading it every time, but it still means we have to check it every time even if it's not being used to set special headers

[Lull3rSkat3r]

Putting the original implementation ideas here to record in case we change implementations in the future:

Implementation 1: Display Data

The python kernels already use the display data module to set outputs for specific types. For my particular use case, I believe this could be achieved today by writing the following code:

# GET /foo/bar
from IPython import display
response_dict = { 'foo' : 'bar' }
response_type = get_response_type() # Assumes we will be able to get the accept header
response_value = serialize_response(response_type, response_dict)
display.publish_display_data({
    response_type : response_value
})

The only implementation needed in the kernel gateway would be to do the following:

1. Check if there is an accept header
2. Look at the display data returned from the cell execution and see if the accept header mime-type is in the message
3. Return appropriate value based on the step above

Advantages

• There is an implementation, which can be referenced by other kernels, in the python kernel.
• The API is fairly simple and would look fairly similar across multiple languages
• This can help the ambiguity in returning values by making this the standard way to return values for consumption by the kernel gateway

Disadvantages

• Requires an implementation of Display Data for the current kernel

Implementation 2: Comm API

We can provide a comm channel API which will allow for objects to be created which will relay the response information to the kernel gateway. An example implementation could look like this:

from KernelGateway import Response
# GET /foo/bar
response_dict = { 'foo' : 'bar' }
response_type = get_response_type() # Assumes we will be able to get the accept header
response_value = serialize_response(response_type, response_dict)
Response(response_value, type=reponse_type, status=200)

Advantages

• Will provide us flexibility in defining what the API is going to be (this can help in other areas such as setting the HTTP response status code or any other response values)

Disadvantages

• Will need to setup implementations across all supported kernel, which could be taxing on resources for development.
• Requires all kernels to provide an API to interact with comm channels from within the kernel (which I believe would also be required from implementation 1)
• Will require a kernel_gateway plugin to run code to setup the comm channels (either as an extension or by interacting with the kernel directly)

[Lull3rSkat3r]

pr #70 will close this.

[parente]

Merged. For anyone else following along, README has the final design.