[IPython-dev] Hierarchical notebook listing

Matthias BUSSONNIER bussonniermatthias at gmail.com
Mon Feb 25 12:28:28 EST 2013


I had a quick look at the code, but let's not talk about implementation. 
I think the question of the dashboard/filesystem is a delicate one. 

I already tried to hack a few things on it and I think it require a clear definition  of what need to be done on the api side before refactoring it. 

The things that we need to considere are :
	- our web app is not the only client of the api (Emacs client) 
        - backend can be databases

So even if tree is a nice representation for filesytem (and I totally agree that in some case being able to see notebook a few level deeper than the current
would be so much useful) It can't apply everywhere. 

There is also the problem that right now, the *kernel* starting directory is the same that the notebook dir, and with a tree view you can start it either on the root, or in the path of the launched ipynb.
And right now, this is also a problem with db backend.

On a performance side, walking all the filesystem to find all ipynb file is not very optimal neither, but we can surely hook onto indexing software to do that,  and/or limit the depth.

We discussed about this stuff during our last meeting, and there is also the issue with the naming/title of notebook. 
Notebook have a  "document name" (could be different from filename) that **have to** be available **without** parsing the JSON. 
in filesystem this is done with the filename. There is again an issue with database. 

Dashboard might/ will need to know if a notebook 
	- is already attached to a kernel, 
	- if already opened in a new page
	- if other users are using it.  

Finally, there is an issue with the unique uuid, that we wish to make persistent across notebook launching. 

From at least this, and maybe other point, we should find a correct data structure that should accommodate both the backend (data base/ filesystem) and the 
dashboard as much as possible.

	- we could include metadata in the message that could apply only on some specific dashboard. 
	- we can't do with only one dashboard, there are specificities we can't deal with. 

About The PR: 
	- It it **really** nice to see fixes on existing javascript
	- And tests !

But I do think we need to think about the data we send on the wire **before** going this way.

Just my reflexion on this.

BTW, One thing I would really **love** is having my started notebook on the top of my list, and being able to filter through the list !

Le 25 févr. 2013 à 11:03, Robert Young a écrit :

> Hi,
> This email is intended to start a conversation around hierarchical notebook listings. I submitted a pull request [1] and it was pointed out that supporting directories deserves some thought and discussion.
> Rob
> [1] https://github.com/ipython/ipython/pull/2977
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130225/b6170d30/attachment.html>

More information about the IPython-dev mailing list