[IPython-dev] Notebook filename badness
Brian Granger
ellisonbg at gmail.com
Tue Jun 26 21:10:04 EDT 2012
On Tue, Jun 26, 2012 at 5:36 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 27 June 2012 01:17, Brian Granger <ellisonbg at gmail.com> wrote:
>> * Because notebook ids are not persisted between sessions of the
>> notebook server, you can't refer to them by URL and reload notebook
>> pages between server restarts.
>
> This may well be stupid, but is there a good reason we can't, with a
> filesystem-based store, use URLs like
> "http://localhost:8888/my_notebook.ipynb"? Even if that simply
> redirects to a UUID-based URL, it would mean there's a predictable way
> to get to them.
This example is a perfect illustration of the problem with the
"notebook name = unique identifier" model:
* Notebook renames become nearly impossible to manage.
- Once a rename is done, the URL has to be updated. For that you
need to either i) reload the page or ii) muck with URL rewriting.
- Even if you can solve that, you can only solve it for the notebook
web page instance where the rename took place. If you have that
notebook open in another tab, that other tab will not see the rename
and will subsequently write to the old filenames upon save.
- If a user renames a file while the notebook server is running,
things get into an inconsistent state.
- I actually coded this up last summer when I got started two
different times and there was no way to make it work acceptably.
- These problems exist even for a single local user.
* These URLs in practice are not that pretty because they have to be escaped.
* Sharing/publishing becomes impossible:
Alice: Here Bob, have a look at this cool notebook I created.
Bob: Alice, I finally got around to looking at the notebook you
shared with me, but I am getting a 404.
Alice: Hmm, I don't know what happened, I can see it fine.
Bob: Did you rename it?
Alice: Oh, crap, here is the new URL.
The reason Google Docs works so well for sharing is that they use
guids in their URLs. Anyone can change the name at any time.
>> Note, I am not proposing that we do away with the existing notebook manager. We should continue to support it, but we should *not* try to fix its the fundamental problems it has.
>
> The notebook has proven very valuable as a local application, and I
> think we should make it work well for that case as well as the webapp
> case, even if that means some extra complexity in the code. Maybe I
> haven't properly grasped the complexities involved, but the idea that
> we should accept fairly serious problems with local use, and focus on
> it as a web application, leaves a bad taste in my mouth.
What I am proposing would *improve* local use dramatically:
* Persistent URLs that you can bookmark and reload across sessions.
* No more worrying about accidentally renaming/uploading over an
existing notebook.
* A natural place for autosave files.
> Also, I don't think these problems are entirely unique to the file
> system. Notebooks stored in a database still need human readable
> names, and I'd still expect some way to handle conflicts in those.
> Meaningful URLs would also be nice, regardless of the storage used.
When notebook are written to any database'y storage backend, they are
referred to by some guid. The human readable names don't have to be
unique. This is true of whether we are using Azure Blob Storage, AWS
3D, mongodb, or a traditional relational db.
The one point that I *don't* like about my proposal is that version
controlling filenames with guids would be ugly. But this is why we
need to keep our existing notebook manager. I am also not convinced
we can get creative in terms of how notebooks are version controlled.
Don't know what that looks like, but I think we need to think more
about it.
Cheers,
Brian
> Best wishes,
> Thomas
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com
More information about the IPython-dev
mailing list