Closed rgbkrk closed 7 years ago
@jasongrout as you are already working on the n=2 case for JupyterLab, it would be great to see some specification of widgets, so that alternate frontends can understand what they need to implement.
Great idea! Though my n=2 case is just reusing the current implementation, so it's still really n=1.
We can write up what we are currently doing, and go from there - this might be a good opportunity to take a step back and decide if we want to make changes.
I guess it's just the bootstrapping part that's not in common, but I think that's also the part that's least defined. Once a Widget is fully hooked up, it's a pretty simple spec.
The julia widgets achieve n=2 on the back-end side.
If at all possible I'd love to see a protocol that's off the comms messages, so it's finely scoped (not global). My intention for wanting this is the ability to iframe, lazy load cells, or even just not have outputs all the time.
The other big thing I'd like to get out of this is an understanding of what widget models mean with respect to a notebook document.
The full duplex mode of the ipywidgets is one thing -- I'm really curious about a reduction of state into two "views":
The screenshots are cool, not what I'm looking for. The other big reason I care here is that these models need to be consistent if there are multiple clients with the same notebook open (the model itself is synced) -- yes, I'm aiming at realtime collaboration.
This was documented in #1215.
It would be great to have the protocol for the widgets declared in a way that any frontend can use.