[IPython-dev] thoughts on the notebook, alternative front-ends and remote editing
Nicholas Bollweg
nick.bollweg at gmail.com
Wed Mar 4 13:00:50 EST 2015
Good discussion.
I for one would hate to see losing the momentum of a powerful web-based
computing environment to start implementing stuff for editor-of-the-week
(no offense). The notebook has the (already observed) potential to bring
interactive computing to people that would never download a programming
editor.
What about codemirror is lacking? Let's build it! Marijn is a really
awesome dude, but can't build everything himself :)
Not to pre-empt Thomas and Matthias, but I have started hacking together a
proof-of-concept architecture that moves the state of the
notebook-being-used into another model that neatly handles persistence and
multiple users. Disclaimer: it doesn't really work yet!
</>
https://github.com/nrbgt/derby-notebook
When the user requests a notebook, its contents are pulled off the content
manager and rebuilt into an evented model. This model includes everything
from the original content, but adds enough stuff to make the state of the
UI persistent:
- notebook
- kernel
- state
- cell
- id
- position in a linked list <- current sticky wicket!
- state
- user
- id
- current cell/mode
- widgets <- haven't started yet
Then one or more clients (browsers or daemons) subscribe to and publish
deltas to this model, which eventually get persisted to the backend and
other clients. Because each client has its own local model, it is robust
against latency, etc. and you don't have to make the decision between
"updating the DOM" vs "updating the model" vs "sending an event"... there
is only the model.
I don't think there is a compelling way to make _repr_javascript_ work with
this, but widgets are *perfect* as they already work this way... though it
may require adding an additional View.view_model if there are UI things
that one would want to share among many users.
Pics or it didn't happen:
[image: Inline image 1]
Right now, codemirror is doing a great job of handling text deltas between
n browsers. The issue arises in correctly handling inserted/moved cells,
and I'm working with the authors of derby, the application framework, to
get these sorted out!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150304/862b9f57/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2015-03-03_1848.png
Type: image/png
Size: 321581 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150304/862b9f57/attachment.png>
More information about the IPython-dev
mailing list