Make the widget update message the same no matter the direction of syncing.

Author: jasongrout

ipywidgets/widgets/widget.py

@@ -508,14 +508,12 @@ def _handle_msg(self, msg):
         data = msg['content']['data']
         method = data['method']
 
-        # Handle backbone sync methods CREATE, PATCH, and UPDATE all in one.
-        if method == 'backbone':
-            if 'sync_data' in data:
-                # get binary buffers too
-                sync_data = data['sync_data']
+        if method == 'update':
+            if 'state' in data:
+                state = data['state']
                 if 'buffer_paths' in data:
-                    _put_buffers(sync_data, data['buffer_paths'], msg['buffers'])
-                self.set_state(sync_data) # handles all methods
+                    _put_buffers(state, data['buffer_paths'], msg['buffers'])
+                self.set_state(state)
 
         # Handle a state request.
         elif method == 'request_state':

jupyter-js-widgets/src/widget.ts

@@ -237,12 +237,13 @@ class WidgetModel extends Backbone.Model {
             if (msg.content.execution_state ==='idle') {
                 // Send buffer if this message caused another message to be
                 // throttled.
+                // TODO: make sure this is handled just like the original syncing.
+                // Right now, it doesn't take into account the new binary_paths key
                 if (this.msg_buffer !== null &&
                     (this.get('msg_throttle') || 1) === this.pending_msgs) {
                     var data = {
-                        method: 'backbone',
-                        sync_method: 'update',
-                        sync_data: this.msg_buffer
+                        method: 'update',
+                        state: this.msg_buffer
                     };
                     this.comm.send(data, callbacks);
                     this.msg_buffer = null;
@@ -398,8 +399,8 @@ class WidgetModel extends Backbone.Model {
             // on the python side the inverse happens
             var split = utils.remove_buffers(state);
             this.comm.send({
-                method: 'backbone',
-                sync_data: split.state,
+                method: 'update',
+                state: split.state,
                 buffer_paths: split.buffer_paths
             }, callbacks, {}, split.buffers);
         }).catch((error) => {

jupyter-widgets-schema/messages.md

@@ -210,7 +210,7 @@ In order to display widgets in both the classic notebook and JupyterLab, ipywidg
 
 
 
-# Widget messaging protocol, version 2
+# Widget messaging protocol, version 2 (not finalized)
 
 A Jupyter widget has both a frontend and kernel object communicating with each other using the `comm` messages provided by the Jupyter kernel messaging protocol. The primary communication that happens is synchronizing widget state, represented in the messages by a dictionary of key-value pairs. The Jupyter widget messaging protocol covers `comm` messages for the following actions:
 
@@ -227,6 +227,8 @@ Throughout this document, relevant parts of messages to the discussion are quote
 
 The `jupyter.widget.version` comm target and associated version validation messages are gone. Instead, it is up to the package maintainers to ensure that the versions of the packages speak the same widget message protocol. We encourage kernel and frontend package developers to clearly indicate which protocol version the package supports.
 
+The sync update event from the frontend to the kernel was restructured to have the same field names as the event from the kernel to the frontend, namely the method field is `'update'` and the state data is in the `state` attribute.
+
 ## Implementating the Jupyter widgets protocol in the kernel
 
 In this section, we concentrate on implementing the Jupyter widget messaging protocol in the kernel.
@@ -275,9 +277,9 @@ The type of widget to be instantiated in the frontend is determined by the `_mod
 
 ### State synchronization
 
-#### Synchronizing from kernel to frontend: `update`
+#### Synchronizing widget state: `update`
 
-When a widget's state changes in the kernel, the changed state keys and values are sent to the frontend over the widget's comm channel using an `update` message:
+When a widget's state changes in either the kernel or the frontend, the changed state keys and values are sent to the other side over the widget's comm channel using an `update` message:
 
 ```
 {
@@ -298,26 +300,7 @@ Comm messages for state synchronization may contain binary buffers. The optional
 
 See the [Model state](modelstate.md) documentation for the attributes of core Jupyter widgets.
 
-#### Synchronizing from frontend to kernel: `backbone`
-
-When a widget's state changes in the frontend, the changed keys are sent to the kernel over the widget's comm channel using a `backbone` message:
-
-```
-{
-  'comm_id' : 'u-u-i-d',
-  'data' : {
-    'method': 'backbone',
-    'sync_data': { <dictionary of widget state> }
-    'buffer_keys': [ <optional list of state keys corresponding to binary buffers in the message> ]
-  }
-}
-```
-
-The state update is split between values that are serializable with JSON (in the `data.sync_data` dictionary), and binary values (represented in `data.buffer_keys`).
-
-The `data.sync_data` value is a dictionary of widget state keys and values that can be serialized to JSON.
-
-Comm messages for state synchronization may contain binary buffers. The `data.buffer_keys` optional value contains a list of keys corresponding to the binary buffers. For example, if `data.buffer_keys` is `['x', 'y']`, then the first binary buffer is the value of the `'x'` state attribute and the second binary buffer is the value of the `'y'` state attribute.
+TODO: update protocol for changes in https://github.com/ipython/ipywidgets/pull/1194
 
 #### State requests: `request_state`