Skip to content

Commit 6518816

Browse files
authored
Merge pull request #3387 from meeseeksmachine/auto-backport-of-pr-3380-on-master
Backport PR #3380 on branch master (Edit and expand docs for jupyter.widget.control comm channel)
2 parents 9b12cc1 + b84679e commit 6518816

File tree

1 file changed

+7
-3
lines changed

1 file changed

+7
-3
lines changed

packages/schema/messages.md

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -370,11 +370,11 @@ This is implemented in ipywidgets 7.7.
370370

371371
### The `jupyter.widget.control` comm target
372372

373-
A kernel-side Jupyter widgets library registers a `jupyter.widget.control` comm target that is used for fetching all widgets states through a "one shot" comm message (one for all widget instances). Unlike the `jupyter.widget` comm target, the created comm is global to all widgets,
373+
A kernel-side Jupyter widgets library may optionally register a `jupyter.widget.control` comm target that is used for fetching all kernel widget state through a single comm message.
374374

375375
#### State requests: `request_states`
376376

377-
When a frontend wants to request the full state of a all widgets, the frontend sends a `request_states` message:
377+
When a frontend wants to request the full state of all widgets from the kernel in a single message, the frontend sends a `request_states` message through the `jupyter.widget.control` comm channel:
378378

379379
```
380380
{
@@ -385,7 +385,7 @@ When a frontend wants to request the full state of a all widgets, the frontend s
385385
}
386386
```
387387

388-
The kernel side of the widget should immediately send an `update_states` message with all widgets states:
388+
The kernel handler for the `jupyter.widget.control` comm target should immediately send an `update_states` message with all widgets states:
389389

390390
```
391391
{
@@ -401,3 +401,7 @@ The kernel side of the widget should immediately send an `update_states` message
401401
}
402402
}
403403
```
404+
405+
Comm messages for state synchronization may contain binary buffers. The `data.buffer_paths` value contains a list of 'paths' in the `data.states` object corresponding to the binary buffers. For example, if `data.buffer_paths` is `[['widget-id1', 'x'], ['widget-id2', 'y', 'z', 0]]`, then the first binary buffer is the value of the `data.states['widget-id1']['x']` attribute and the second binary buffer is the value of the `data.states['widget-id2']['y']['z'][0]` state attribute. A path representing a list value (i.e., last index of the path is an integer) will have a `null` placeholder in the list in `data.states`, and a path representing a value for a dictionary key (i.e., last index of the path is a string) will not exist in the dictionary in `data.states`.
406+
407+
Since the `update_states` message may be very large, it may be dropped in the communication channel (for example, the message may exceed the websocket message limit size). For that reason, we suggest that frontends fall back to other ways to retrieve state from the kernel if they do not get an `update_states` reply in a reasonable amount of time.

0 commit comments

Comments
 (0)