
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>Le 4 mars 2015 à 10:00, Nicholas Bollweg <<a href="mailto:nick.bollweg@gmail.com">nick.bollweg@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>Good discussion.<br><br></div><div>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.<br><br>What about codemirror is lacking? Let's build it! Marijn is a really awesome dude, but can't build everything himself :)<br></div><div><br></div>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: <a href="x-msg://10/">it doesn't really work yet!<br></a></div></div></div></div></blockquote><div><br></div><div>That's great that the long time goal too, </div><div>Haven't had a deep look yet, but will. </div><div><br></div><div>How much does it rely on derby/nodejs being there ? </div><div><br></div><div>The proxy was one of the things I though about, but I'm not sure that completely the way we want to go.</div><div>But let see.</div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div><span id="goog_1904078995"></span><br><a href="https://github.com/nrbgt/derby-notebook" target="_blank" rel="nofollow">https://github.com/nrbgt/derby-notebook</a><br><br></div><div>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:<br></div><ul><li>notebook<br></li><li>kernel</li><ul><li>state<br></li></ul><li>cell</li><ul><li>id</li><li>position in a linked list <- current sticky wicket!</li><li>state</li></ul><li>user</li><ul><li>id</li><li>current cell/mode</li></ul><li>widgets <- haven't started yet</li></ul></div></div></div></blockquote><div><br></div><div>That's nice, I really want to decouple the notebook model which is on disk to the on memory one. </div><div>I'm pondering not a list for cell, but actually dict of id-> cell plus a list of id order. </div><div><br></div><div>that should make partial update simple. </div><div><br></div><div>thought ? </div><div><br></div><div>I really want to think about user UI state that is synced vs the one that is not synced. </div><div>For example I doubt the hidden state of cell toolbar should be synced. </div><div><br></div><div>Same with collapse state of output area. </div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div>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.<br><br></div>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.<br></div></blockquote><div><br></div><div>reprjs make sens for "static widget" (mpld3m or Julia Gadfly) that allow in browser panning and zooming. </div><div><br></div><div><br></div><div>I would really like building the structure of the notebook in a way that the realtime backend would be plug able. </div><div>WE also need to think carefully about the execution logic. I would like to have real-time where I would be able to execute,</div><div>but the people I share with would not. </div><div><br></div><div>I suppose we would need to bake login into RT framework. How do you handle that for now ? </div><div><br></div><div>Should we make a place just to discuss realtime collaboration ?</div><div><br></div><div>-- </div><div>M </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><br><div>Pics or it didn't happen:<br></div><div><span><2015-03-03_1848.png></span><br><br></div><div>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!<br></div><div><br></div></div></div>

_______________________________________________<br>IPython-dev mailing list<br><a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/ipython-dev<br></blockquote></div><br></body></html>