Ondrej,<br><br>I have have thought about possible notebook formats many times.  IPython has partially implemented at least two different notebook formats.  Both of them have not been very successful.  The first was XML based and the second was based on an sqlalchemy db.  Both were insanely complex.<br>
<br>Fernando and I have talked many times about a notebook format that is simply restructured text.  There are many advantages of this approach:<br><br>* All of us use reST for lots of things any ways.<br>* There are existing parsers for reST.<br>
* It naturally knows about code + text.<br>* Latex support, graphics.<br>* And more.<br><br>In many respects it seems almost perfect.  But, one day recently I was thinking about how successful Mathematica&#39;s notebook continues to be.  So I began to look more at the Mathematica notebook format.  Amazingly, the Mathematica notebook format is a plain text file that itself is *valid Mathematica code*.  This id documented here:<br>
<br><a href="http://reference.wolfram.com/mathematica/guide/LowLevelNotebookProgramming.html">http://reference.wolfram.com/mathematica/guide/LowLevelNotebookProgramming.html</a><br><br>For examples a simple notebook with one text cell is just:<br>
<br>Notebook[{Cell[&#39;Here is my text&#39;, &#39;Text&#39;]}]<br><br>Everything - input cells, output cells, static images and all are represented in this way and embedded in the plain text notebook file.  The Python generalization of this would be the following:<br>
<br>* A Python notebook is plain text, importable Python code.<br>* That code is simply a tree of objects that declare the relevant parts of the notebook.<br><br>This has a number of advantages:<br><br>* A notebook can be imported, manipulated and run by anyone who has the support code (the notebook module that defines the relevant classes).<br>
* A notebook doesn&#39;t need to be parsed.  It is valid Python and can be imported or exec&#39;d.  Once that is done, you have the full notebook in memory.  You can immediately do anything you want with it.<br>* The various Notebook, Cell, Image, etc. classes can know about how to output to various formats, latex, html, reST, XML, etc:<br>
<br>import mynotebook<br>mynotebook.notebook.export(&#39;rest&#39;)<br><br>* Each individual format (HTML, reST, latex) has weaknesses.  If you pick any one to be *the* notebook format, you are building those weaknesses into your design.  A pure python based notebook format won&#39;t suffer from that syndrome.<br>
* It is a clean separation of the model (Notebook, Cell, Image, etc.) and the view (HTML, reST, etc.).  Picking HTML or reST for the notebook format confuses (at some level) the model and view...<br>* Third party code can define new Notebook elements that specify how they can be rendered in different contexts.  For example, matplotlib could ship a Figure element that knows how to render itself as a native PyQt GUI, a static image, a web page, etc.<br>
* A notebook remains a single plain text file that anyone can edit - even if it has embedded images.  Neither HTML nor reST have the ability to inline graphics in plain text files.  While I love reST, it is a pain that I need an entire directory of files to render a single Sphinx doc.<br>
<br>Anyways, that is where my brain is wandering these days.<br><br>Cheers,<br><br>Brian<br><br><br><br><br><div class="gmail_quote">On Tue, Feb 16, 2010 at 6:21 PM, Ondrej Certik <span dir="ltr">&lt;<a href="mailto:ondrej@certik.cz">ondrej@certik.cz</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br>
<br>
has anyone given a deeper thought how to best implement this functionality?<br>
<br>
Currently the Sage notebook seems to remember the worksheet using:<br>
<br>
--------------<br>
sdsd<br>
system:sage<br>
<br>
<br>
&lt;p&gt;Well, some text&lt;/p&gt;<br>
<br>
{{{id=5|<br>
awe<br>
///<br>
}}}<br>
<br>
{{{id=1|<br>
4<br>
///<br>
4<br>
}}}<br>
<br>
{{{id=2|<br>
5<br>
///<br>
5<br>
}}}<br>
<br>
{{{id=3|<br>
<br>
///<br>
}}}<br>
---------------------<br>
<br>
E.g. each cell is either a text cell, or a cell that can be evaluated.<br>
Is that right?<br>
<br>
I know that Fernando suggested here:<br>
<br>
<a href="http://groups.google.com/group/sage-devel/browse_thread/thread/3f1f5a0c26975519/" target="_blank">http://groups.google.com/group/sage-devel/browse_thread/thread/3f1f5a0c26975519/</a><br>
<br>
to use reST, e.g. something like:<br>
<br>
----------<br>
Well, some text<br>
<br>
::<br>
     &gt;&gt;&gt; print 3<br>
     3<br>
<br>
------------<br>
<br>
<br>
I am implementing a notebook prototype using pure Python<br>
(automatically translated to javascript using pyjamas) and I would<br>
like to run it on the google app engine (the javascript in your<br>
browser would then communicate either with the app engine, or your own<br>
hardware that would host Sage/FEMhub/your own code):<br>
<br>
<a href="http://gamma.sympy.org/nb/" target="_blank">http://gamma.sympy.org/nb/</a><br>
<br>
and here is my development version with logins and settings implemented:<br>
<br>
<a href="http://2.latest.sympy-gamma.appspot.com/nb/" target="_blank">http://2.latest.sympy-gamma.appspot.com/nb/</a><br>
<br>
now I need to implement the worksheets, so I am thinking how to best<br>
represent it.<br>
<br>
<br>
Did the syntax for input/output blocks in Sphinx settled already? I<br>
guess internally I will implement the worksheet as a set of cells,<br>
either text cells, or &quot;evaluatable&quot; cells (that contain both<br>
input/output blocks) and then support conversion to and from<br>
reST/Sphinx.<br>
<br>
I would be interested in any feedback.<br>
<br>
Ondrej<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</blockquote></div><br>