Tom,<div><br></div><div>I understand you&#39;re frustrated by losing your work. It&#39;s completely understandable, and we&#39;ve all been there. But please consider your tone carefully, and try to remember that (nearly?) everyone working on IPython is doing so on a volunteer basis, in their spare time.</div>
<div><br></div><div>The core developers on this project, Thomas and Matthias included, are a clever bunch, and tend not to want to &quot;half-ass&quot; things. Despite IPython&#39;s long history, the notebook is less than a year old -- and given the reception it has received from the community, many would agree that it was worth the wait -- but, despite the tremendous effort behind the transition to a two process model and the implementation of the notebook infrastructure and client, it is still not quite a finished product. Matthias has briefly outlined some of the technical considerations involved in getting autosave functionality done in a clean, transparent and future-proof manner. I can think of a few other snags and possible solutions but Matthias is far more familiar with the notebook&#39;s codebase than I am. In an application with as many moving parts as the notebook, the actual implementation is always going to be more complicated than it seems in a high-level bullet-point description, and in an application with an API, users expect stability of that API -- quickly and arbitrarily changing things to accomodate autosave might be doable without changes to that API, it might not, but either way it is not something that can be undertaken lightly. Perhaps worse is the possibility of introducing new APIs, realizing they suck, and having to deprecate them in favour of the &quot;right&quot; solution, resulting in frustration on the part of people who have, in the mean time, come to depend on those APIs.</div>
<div><br></div><div>I agree with you that it&#39;s a very important feature, one that I would love to see. But between all of the currently open bugs and the limited amount of developer bandwidth, plus the availability of Min RK&#39;s extension as a short-term fix, it may be a while before the developers have the time to devote in order to get it right.</div>
<div><br></div><div>But code talks. If you truly believe both that this is an important feature (I&#39;m with you on that one), and that the right design decisions are self-evident/the implementation is straightforward (I&#39;m a good deal less certain about that), give it a go and open a pull request. It probably will not suffice right off the bat, but it will get developers thinking about it and paying attention to it sooner (it is much easier to reason about and offer constructive criticism about a concrete implementation than the abstract idea of one). Provided you have the time and patience, they can guide you in the direction of improving it to the point that merging might be an option. Importantly, do not think of a pull request as an accept/reject patch submission. GitHub themselves[1] describe their use of pull requests as a way to &quot;start a conversation&quot; about a feature and receive feedback about it as it evolves, and in my experience this is a healthy model of pull request-driven development.</div>
<div><br></div><div>I apologize if I&#39;ve read more hostility into your posts than there actually was, but in virtually all cases, you will catch more flies with honey than with vinegar. That is to say, no one expects you to be a sycophant or a suck-up, but please try to temper your understandable agitation with the knowledge that the developers have only the best intentions for improving and maintaining IPython for *all* of its users, and moreover that they do so in spare moments of otherwise busy careers/lives, largely without compensation of any kind. Approaching conversations like this with both a calm tone and an open mind will invariably get us all further toward solving the problem.</div>
<div><br></div><div>Regards,</div><div>David</div><div><br></div><div>[1]: <a href="https://github.com/blog/1124-how-we-use-pull-requests-to-build-github">https://github.com/blog/1124-how-we-use-pull-requests-to-build-github</a></div>
<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 4:55 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The take-home message from your response is that iPython Notebooks are not going to get any form of autosave or crash protection any time soon, and that if there is data loss from crashes, you consider it the user&#39;s fault. </div>


<div><br></div><div>Since there hasn&#39;t been any other response to this, I assume that&#39;s official iPython policy.</div><div><br></div><div>Thanks for taking the time to clarify this.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>Tom</div></font></span><div class="HOEnZb"><div class="h5">

<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 10:15 AM, Matthias BUSSONNIER <span dir="ltr">&lt;<a href="mailto:bussonniermatthias@gmail.com" target="_blank">bussonniermatthias@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 7 nov. 2012 à 03:01, Tom a écrit :<br>
<div><br>
&gt; &quot;This is all solvable, but it would be a significant expenditure of time and effort, and so far no-one&#39;s got round to doing it.&quot;<br>
&gt;<br>
&gt; It only becomes a significant expenditure of effort because people are trying to reinvent the wheel and mix this issue up with unrelated and complicated issues of backup files, multiple instances, version control, and god knows what else. In fact, autosave is pretty simple:<br>



<br>
</div>Even if you consider &#39;just autosaving&#39; it is a pretty big amount of work. Especially if it is not done correctly, because we will have to deal with legacy code, but let&#39;s forgot this one.<br>
<div><br>
&gt; - periodically, you save the notebook to an autosave file, but only if it has been modified<br>
</div>Ok, let&#39;s say timer in javascript.<br>
The API to do so does not exist. I once try to use the &quot;save as&quot; function in JS periodically, but &quot;save as&quot; is actually &quot;rename&quot;, and I lost a day of work.<br>
So you&#39;ll need to create a &quot;save_copy(name)&quot; API. (Potentially breaking API that other client rely on, meaning at least 1 version with deprecation warning and design legacy mode option?)<br>
<div><br>
&gt; - autosave only saves user input (which is all text fairly small), not the output or images<br>
<br>
</div>Gaps, ok, I have to patch cell, codecell, markdowncell, header cell, raw cell, in JS, which none of us really know.<br>
Think of future cell types that might inherit and should also be saved.<br>
<br>
Add a method which &#39;serialize input only&#39; of notebook. Shouldn&#39;t be too hard, design a API that send a notebook through the wire that have only inputs.<br>
<br>
Do you send only input or ipynb file strip of output ? are they &quot;real ipynb file&quot;?, do you keep metadata ? Cell type ? Prompt number ?<br>
<br>
If some fields are not existing or empty, do you save them or not ? You might not care, but the server does. If you forget require field then backup files are un readable, if you put unnecessary one, you are doing too much work for nothing.<br>



<br>
Now, for long notebook, serialization you will might feel a hang in the browser every now and then, hopefully nobody will complain.<br>
<div><br>
&gt; - the autosave file for &quot;filename.ipynb&quot; is &quot;#filename.ipynb#&quot; in the same directory<br>
</div>Whatever the filename, maybe leading dot to have it hidden. Still be carefull with extension.<br>
If it end with ipynb you have to take care of not showing it into the dashboard.<br>
Btw, we have many possible backend, how do you do when the backend is not a filesystem base but a database ?<br>
<div><br>
&gt; - the autosave file is removed whenever a manual save takes place (and only gets recreated once there are modifications)<br>
</div>This is a little more complicated as the server does not have notion of wether the browser have a modified version, but doable.<br>
The subject of backup files has been discussed on the ml before, the deletion of them is a complex problem, even emacs and vi user are sometime complaining about not deleted swap file. Let&#39;s assume everyone agree on a how/where to save so that you don&#39;t have to make the all thing configurable.<br>



<div><br>
<br>
&gt; - when you open a file, you check whether there is an autosave file for it and offer the user to recover it, open it as a new file, or delete it<br>
</div>Ok, now you need a full interaction between server and browser, with dialog, handler, thinking of all possible actions.<br>
Knowing that some other programs (like emacs) also speak to server, you need to design an API, document it.<br>
<br>
You probably wan&#39;t to add that in the dashboard.  Even it dashboard look simple, the code is not that easy.<br>
<br>
<br>
You probably want the user to be able to browse the 2 files independently before choosing which one to keep.<br>
(we won&#39;t try yet to show a diff between 2 ipynb files...).<br>
<br>
So this means now that the server should be able to let you open ipynbfiles that are not ipynb files, so that are not listed in some places,<br>
but listed in others, and attach kernel to it (probably), otherwise you need a RO view which is non functional right now.<br>
Just to be sure, when you open a file for a fist time it started a kernel ? right ? and to shut down this kernel, you... Click on shutdown on the dashboard.<br>
But backup files are not shown ! How do I shut down their kernel ?<br>
<br>
(Btw this might be a bug, if you delete a file from the file explorer, what become of its kernel, can you shut it down easily?)<br>
<div><br>
<br>
&gt; If doing autosave well over slow connections looks too complicated, just turn it off for slow/remote conections and put up a warning indicator in the menu bar; autosaving 95% of the time is a lot better than autosaving 0% of the time, which is the current situation.<br>



<br>
</div>Then we need to define &quot;slow&quot;, if you want to make it configurable (even enable/diasble), then you have to design way to push config from server to browser.<br>
Which is right now not existing at all.<br>
<div><br>
&gt; &quot;Perhaps it&#39;s better to focus on reducing the need for autofocus. As others have said, Ctrl+S should work in all browsers to save the notebook. The original post also mentions problems with long output&quot;<br>



&gt;<br>
&gt; You cannot fix this by trying to fix bugs elsewhere. No matter how many bugs you fix, computers crash, lose power, and get forced reboots from Windows updates. Nor is manual saving a solution because people don&#39;t expect to have to do that anymore and simply will not remember. I don&#39;t remember to (even now that it works), which is why I keep losing work in iPython.<br>



<br>
</div>Now you have something working, maybe configurable, maybe not.<br>
It is not well designed but it does it job, it took you a full day, pull request not included, you didn&#39;t add test_case, and even don&#39;t bother testing on windows.<br>
Now you want to redesign the notebook to handle files in multiple directory.<br>
Well basically now you curse yourself, because you have twice as much things to redisign and it would take you 2 weeks instead of one, and you will break other people code that rely on what you did.<br>
<div><br>
&gt; Implementing autosave is a small task and easily done if you decide to do it, and it greatly alleviates the pain resulting from many other bugs.<br>
<br>
</div>We do care that people lost data some of their work, and we want to avoid it as much as possible. The problem is that we have to balance between doing things the right way, at the right time or hacking something in a afternoon, and being able to relatively easily add new features.<br>



<br>
Having a full blown autosave as part of IPython notebook is far from being as &#39;easily done&#39; as you think. We&#39;ll do our best make it as easy as possible to do what you want. It will just require sometime to wait for the feature to be ready, in the meantime, you will have to inject some of you code directly into IPython.<br>



<br>
Just to finish on a personal note.<br>
In some class, we warn student, &quot;please regularly save you work&quot; we even remind them every 10-20 minutes during the exams.<br>
A colleague of my tell them &quot;I will cut the power when the time is over&quot;, and once  the time is over it count down from 10 to zero and does effectively cut the power of the all room.<br>
Believe me that after that, student **do** save their work regularly.<br>
<br>
Teaching student not to rely on machines might be a good thing sometime.<br>
<div><div><br>
<br>
&gt; Tom<br>
&gt;<br>
&gt; On Wed, Nov 7, 2012 at 1:44 AM, Jon Wilson &lt;<a href="mailto:jsw@fnal.gov" target="_blank">jsw@fnal.gov</a>&gt; wrote:<br>
&gt; On 11/06/2012 06:19 PM, Carl Smith wrote:<br>
&gt; &gt; it&#39;d probably be more useful if it displayed<br>
&gt; &gt; the amount of time since the last save<br>
&gt;<br>
&gt; Or even (also?) tell you how many cells have changed since the last save.<br>
&gt; Regards,<br>
&gt; Jon<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-User mailing list<br>
&gt; <a href="mailto:IPython-User@scipy.org" target="_blank">IPython-User@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-User mailing list<br>
&gt; <a href="mailto:IPython-User@scipy.org" target="_blank">IPython-User@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br>
_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></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>