On Wed, Nov 7, 2012 at 6:20 AM, Thomas Kluyver <span dir="ltr">&lt;<a href="mailto:takowl@gmail.com" target="_blank">takowl@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_extra"><div class="im"><div class="gmail_quote">On 7 November 2012 12:43, Tom <span dir="ltr">&lt;<a href="mailto:tmbdev@gmail.com" target="_blank">tmbdev@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



(I think lack of autosave should be prio-blocker.)</blockquote></div><br></div>In general, I don&#39;t think we&#39;d block on a new feature. The standard for setting a blocker is &#39;would we wait for this if everything else is ready for a release?&#39; 0.14 will improve on 0.13 even if it&#39;s released without autosave, so it wouldn&#39;t make sense to hold it up for that.<br>



<br>Could you flesh out a detailed description of how an autosave might work, perhaps as an IPEP (<a href="https://github.com/ipython/ipython/wiki/IPython-Enhancement-Proposals-%28IPEPs%29" target="_blank">https://github.com/ipython/ipython/wiki/IPython-Enhancement-Proposals-%28IPEPs%29</a> ). It should describe, for instance:<br>



- What gets saved<br>- Will it be always on, configurable, or &#39;smart&#39;?<br>- Where does it get saved? I don&#39;t like extra files cluttering up my working directory.<br>- What happens if I have the same notebook open in two tabs? Or two computers talking to the same server?<br>



- Notebooks needn&#39;t be stored as files, they could be blobs in a database - how will this be abstracted away from the frontend?<br>- Will autosave files be automatically removed, and if so, when?<br>- How is a crash detected, and what UI presents the autosaves to the user?<br>

</div></blockquote><div><br></div><div>I would also add (actually with any IPEP, not just this one):</div><div><br></div><div>- What needs to be done right the first time, because changing it later would involve nasty API breaks for users? An example in this case is the naming scheme for the autosave files, including the user API for changing their location.</div>

<div>- What can be done poorly at first, and then improved.  I think there should be no guarantees about the format of autosave files (indeed, they don&#39;t even need to be forward compatible, though they could be).  For a first go, the easiest thing would be to just write a complete copy of the notebook.  In iterations, you could move to more efficient things.</div>

<div>- What will you never do, because it is outside the scope of the project?  An example here is reimplement version control. </div><div>- What blocks on even the most basic functionality? It sounds like the ability to have the same notebook open multiple times is one of these.</div>

<div><br></div><div>To me, in this conversation, there is too much mixing with what can be done now and what we would like to have done ideally at some point in the future.  Clearly separating what needs to be done now and what can wait would help on the path to implementing this, I think.</div>

<div><br></div><div>Aaron Meurer</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">

<br>Looking at this differently, I wonder if we could use the localStorage Javascript APIs to do autosaves client-side? I suspect that idea has its share of difficulties, but perhaps it&#39;s worth exploring.<br><br>Thanks,<br>



Thomas<br></div>
<br>_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br></blockquote></div><br></div>