<div dir="ltr">Hi Brian,<div><br></div><div style>Thanks for the clarifications re security etc. and your roadmap.</div><div style><br></div><div style>While Mongo or SQL databases are space inefficient, whether to use them or not depends on whether you want the other things they provide.  One doesn&#39;t generally use them for *efficient* space storage.</div>

<div style>More for integration into MVC webapp frameworks, existing reporting and content management tools etc.  </div><div style>But if storage efficiency dominates your trade-offs then the file system is probably the best.</div>

<div style><br></div><div style>Nitin</div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br clear="all"><div><br>------------------------------------------------------------------<br>

Nitin Borwankar <br><a href="mailto:nborwankar@gmail.com">nborwankar@gmail.com</a></div>
<br><br><div class="gmail_quote">On Sun, Feb 24, 2013 at 10:31 PM, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@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">

Nitin,<br>
<div><div class="h5"><br>
On Sat, Feb 23, 2013 at 4:38 PM, Nitin Borwankar &lt;<a href="mailto:nborwankar@gmail.com">nborwankar@gmail.com</a>&gt; wrote:<br>
&gt; I would like to connect with the IPython team at PyData 2013 in SantaClara<br>
&gt; next month as I have interest in doing the following and would like to<br>
&gt; co-ordinate :-<br>
&gt;<br>
&gt; a) want to create a robust plugin framework for database magics (SQL and<br>
&gt; NoSQL)<br>
&gt;<br>
&gt; I have Postgres working (%%PGDB) right now and aim to do MySQL and Mongo<br>
&gt; (and anything else based on community feedback).<br>
&gt;<br>
&gt; Essentially  (after some database config) you run<br>
&gt;<br>
&gt; &quot;%PGDB &lt;sql query&gt;&quot;  in IPyNB<br>
&gt;<br>
&gt; this executes the query on a PG instance (in your config) via stdin/stdout<br>
&gt; voodoo to the psql client (needs to be locally installed) and returns the<br>
&gt; results set in the output visually as a text based table.<br>
&gt;<br>
&gt; I am hoping to put out the PGDB magic on github before PyData.<br>
&gt;<br>
&gt; Note that I make no attempt to parse SQL or understand the string - if you<br>
&gt; mess up you will hear from the database at the other end as if you were<br>
&gt; sitting at a console in a terminal.  I am just the middle man.<br>
&gt; Or rather %%PGDB is.<br>
&gt;<br>
&gt; Some work is needed to return the result set as a Py dict that is visible in<br>
&gt; the name space so it can be used by other code.<br>
&gt;<br>
&gt; There are some issues to deal with re: keeping a persistent connection so<br>
&gt; that multiple requests don&#39;t open more and more connections - this is now<br>
&gt; running at a basic (optimistic scenario) level but has not been tested for<br>
&gt; all kinds of bad scenarios.<br>
&gt;<br>
&gt; I have used standard &quot;magics&quot; metaphors and just dropped the code in the<br>
&gt; right place and did some config. The integration with the IPyNB system was<br>
&gt; not trivial but it is straightforward enough that it is not rocket science.<br>
&gt; I was very pleased it worked after some elementary brain twisting :-)<br>
&gt;<br>
&gt; Kudos to the IPy team for making extensibility straightforward - this is a<br>
&gt; HUGE WIN.<br>
&gt;<br>
&gt; b)  want to save JSON .ipynb in Mongo, Postgres key-value store and other<br>
&gt; JSON stores instead of the filesystem in current directory.<br>
<br>
</div></div>Our notebook manager class is designed to make it possible to add<br>
other storage backends.  Right now we have a file system based one and<br>
another based on Azure blob storage.  It shouldn&#39;t be too difficult to<br>
create a mongodb based one.  However, I think Mongodb is a horrible<br>
choice to use for entire notebooks.  Notebooks can be really big and<br>
mongodb is not very space efficient.<br>
<div class="im"><br>
&gt; c) want to be able to compose (note *compose* not edit) Notebooks via a web<br>
&gt; UI where a user can assemble content chunks (JSON in Mongo) or .... and then<br>
&gt; &quot;publish&quot; to .ipynb compliant JSON.<br>
&gt; This will allow massive reuse of working content chunks especially those<br>
&gt; that involve code examples and diagrams needing reproduceability.<br>
&gt;<br>
&gt; My motivation for doing this is<br>
&gt;<br>
&gt; 1) IMHO, the filesystem based storage is subject to OS level security issues<br>
&gt; and the database storage *may* (huge big MAY) provide some mitigation.<br>
&gt; Caveat being don&#39;t naively assume that database security is the whole<br>
&gt; answer.<br>
<br>
</div>The big security issues related to the notebook are not the file<br>
system, but the fact that users can run arbitrary code.  Throwing<br>
notebooks in a db won&#39;t help that at all.  In fact, because users can<br>
run arbitrary code, you risk them being able to hack your mongodb<br>
db...<br>
<div class="im"><br>
&gt; 2) while the quantum of shareability right now is the single notebook, which<br>
&gt; is awesome in itself, this can be taken even further. So if one wishes, a<br>
&gt; notebook can be published as a sequence of quasi-atomic chunks which can<br>
&gt; then be separately mixed and mashed.  The quasi-atomic means that we define<br>
&gt; one further level of granularity inside a notebook - the boundaries being<br>
&gt; orthogonal to actual content boundaries. i.e. we should not say e.g. that<br>
&gt; &quot;use a horizontal rule&quot; as a chunk marker - this is brittle etc.<br>
<br>
</div>We have long term plans to think about allowing notebooks to be saved<br>
and loaded on a cell-by-cell basis, but this is pretty far off still.<br>
<br>
At this point, I think you should try to implement everything you want<br>
on your own outside of IPython proper.  In the long term, you may find<br>
that IPython moves in some of these directions, but we are focused on<br>
other things right now:<br>
<br>
<a href="https://github.com/ipython/ipython/wiki/Roadmap:-IPython" target="_blank">https://github.com/ipython/ipython/wiki/Roadmap:-IPython</a><br>
<br>
Cheers,<br>
<br>
Brian<br>
<div class="im"><br>
&gt; 3) Content management becomes easy *in some respects* when the granularity<br>
&gt; is smaller.<br>
&gt;<br>
&gt;<br>
&gt; Thanks for reading this far.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------------------------------------------<br>
&gt; Nitin Borwankar<br>
&gt; <a href="mailto:nborwankar@gmail.com">nborwankar@gmail.com</a><br>
&gt;<br>
</div>&gt; _______________________________________________<br>
&gt; IPython-User mailing list<br>
&gt; <a href="mailto:IPython-User@scipy.org">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>
<br>
<br>
<br>
--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><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>
</blockquote></div><br></div>