[IPython-dev] Hierarchical notebook listing
Fri Mar 1 20:42:56 CST 2013
[[ this may sound like a horrible idea at first but it has legs and has
been used in limited context ]]
I think an "attribute" on the notebook called "accesspath" and an HTTP
resolvable URI ( file:// or http:// or even mongo:// .... ) as a value
makes this OS independent to a first order.
It also allows the storage implementation code to be decoupled from the
client in ways that do not require re-inventing these wheels and reuse of
tons of built-in and well understood code. Also for implementations in
othe languages ( Ruby...) the address remains invariant.
Note: storage in SQL db's is probably best wrapped in a REST API for such
purposes, with a set of CRUD primitives mapped to REST verbs, so we assume
that SQL db's are behind an http:// or https:// scheme.
Bottom line using existing resolvable HTTP URI's for storage addressing
gives both the hierarchy and the decoupling in an IPyNB friendly metaphor
without need to write Yet Another Platform Independent Layer ( YAPIL ? )
[[ long long sidebar: having such an address also allows storage of
notebooks (JSON blobs) in say Apache CouchDB which is an awesome REST
addressable JSON store, which also has very powerful master-master
replication. CouchDB has an efficient storage format that saves embedded
binaries and also allows custom indexes to be created using Map Reduce.
Having your own notebooks and a co-workers notebooks and being able to sync
them on a LAN is effortless, as is syncing them to the cloud. I have used
Apache CouchDB (was the project manager for an NSF funded project in
2008-10) for JSON based bibliographies that could be synced.
A notebook storage in CouchDB + bibliographies in CouchDB would be a very
powerful researchers' publication management platform.
In our project we had spec'ed out what an individual academic's
bibliomanager, a departmental bibliomanager and a univ level biblio manager
would look like. We had also talked to administrators in the UCBerkeley
statistics department to investigate how it would improve their work.
It was not implemented but another system which used CouchDB as a platform
for creating citable URL's for unsolved Math problems was successfully
implemented. It managed inline LaTex using the precursor to MathJax -
JSMath - as MathJax did not exist then. We released on the 150th
anniversary of the Riemann Hypothesis, in 2009, were Slashdotted and
survived even when on a small EC2 instance - CouchDB is very resilient and
manages concurrent requests very very well, in a resource efficient manner.
P.S. I do not sell CouchDB :-) ]]
On Tue, Feb 26, 2013 at 2:47 AM, Matthias BUSSONNIER <
> Le 26 févr. 2013 à 01:49, Brian Granger a écrit :
> > Some of the questions we need to think about:
> > * What does the web service look like to move around and query
> > * Do we map directory paths onto notebook URLS? If so, how?
> > * How do we build a UI/UX that is extremely simple, but functional
> > enough to get the job done.
> > * How do we want to abstract these things for different notebook backend
> IMHO, the "backend" should return a notebook "document name" ( not the one
> store in the json metadata)
> and a UUID when asked to "list" notebook
> The actual content of the notebook when asked.
> The actual "mapping" filesystem/url would be using uuid that are generated
> from hmac and path, so unique, and persistent.
> This also work for database
> | uuid | document_name | content |
> For the UI,
> I can see "breadcrumbs" to navigate in parents directory.
> We could also do something like github, where you show both ipynb and
> folder and you can enter a folder.
> This would require some "custom" data structure that could be exchange
> from dashboard and backend.
> > * How do notebook directories get mapped to kernel cwds?
> > Cheers,
> > Brian
> > On Mon, Feb 25, 2013 at 2:03 AM, Robert Young <firstname.lastname@example.org>
> >> Hi,
> >> This email is intended to start a conversation around hierarchical
> >> listings. I submitted a pull request  and it was pointed out that
> >> supporting directories deserves some thought and discussion.
> >> Rob
> >>  https://github.com/ipython/ipython/pull/2977
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPythonemail@example.com
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > firstname.lastname@example.org and email@example.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPythonfirstname.lastname@example.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> IPython-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev