Use slugs to identify notebook, instead of numeric ids

[wlach]

@jaredkerim suggested using slugs to identify notebooks on the server instead of numeric ids. So e.g.

https://iodide-server.iodide.io/notebook/what-does-an-iodide-notebook-look-like/

instead of (what we currently have):

https://iodide-server.iodide.io/notebook/1/

This (1) makes it easier to identify what a url points to and (2) frees us up to make database changes without breaking users.

[bcolloran]

sounds good, as long as we have a plan for handling the inevitable edge case of having several notebooks with the same name :-)

[djbarnwal]

@bcolloran @wlach We can use GitHub usernames and serve notebooks on a URL like - https://iodide-server.iodide.io/djbarnwal/notebook/what-does-an-iodide-notebook-look-like/

For users who are not logged in, we can reserve a username such as anon or anonymous and present a URL like - https://iodide-server.iodide.io/anon/notebook/what-does-an-iodide-notebook-look-like/

[bcolloran]

@djbarnwal ah oops, i meant the case of a single user having more than one notebook with a shared name. so if you have two notebooks called "test notebook", will you end up with slugs https://iodide-server.iodide.io/djbarnwal/notebook/test-notebook and https://iodide-server.iodide.io/djbarnwal/notebook/test-notebook-2?

i think we don't want to support saving of notebooks anonymously, and it think it makes sense to always just show the user url for the user that created a notebook. so, if you share your notebook with me, i should just see iodide.io/djbarnwal/what-does-an-iodide-notebook-look-like/, and if i want to look at your other notebooks, i should be able to go to iodide.io/djbarnwal/

this is what a lot of sites (e.g. observable) do, and i think it's the right thing. see e.g.: https://beta.observablehq.com/@mbostock/introduction-to-notebooks https://beta.observablehq.com/@mbostock

in addition to name collision, what happens when a user changes the NB title? are they stuck with that slug/url? i ask, b/c i agree that the big advantage here is in readable URLs, and changing project names happens all the time. another scheme might be e.g. iodide.io/${user}/${readable slug}/${id_string} or iodide.io/${user}/${id_string}/${readable slug} (and just ignore the readable slug for routing purposes). I may not be understanding the DB issue, but it seems like some kind of unique key string (rather than an integer) should make DB changes as easy as a slug?

[wlach]

The normal strategy in case of collisions would be to add a -XX string to the end of the slug. i.e.

my-cool-notebook
my-cool-notebook-1
my-cool-notebook-2
...

In practice I expect slug collisions to be a rare event.

Good idea re: associating notebooks with particular users though, I'll try to roll that change in with this one.

[bcolloran]

i was thinking more about this, and again i'm thinking of the case of wanting to change the slug when you change the notebook title -- just want to make sure that is on the radar with this proposal.

This will come up often in the case of forking notebooks. think for example of the workflow that happened when Brendan Meade "forked" (manually at that time) the Lorenz notebook to make his earthquake notebook. The situation would be something like:

• my notebook exists at iodide.io/bcolloran/the-lorenz-attractor-in-iodide
• he would for that to get iodide.io/bmeade/the-lorenz-attractor-in-iodide
• he would then hack on that nb for a while, changing it and it's title to be about earthquakes, so we want to make sure it's possible to update the mapping from slug to notebook id.

[wlach]

Yeah, one detail is how to track notebooks as they are renamed / forked / etc. A proper implementation here may require a fair amount of business logic, but let's see how far we can get with a naive approach that just identifies a particular notebook by its slug + user who created it.

[wlach]

After playing around with this a bit, this seems a lot more complicated to get right than I thought. In particular, being able to track a notebook across renames (which seems like a very important use case) becomes extremely difficult if the slug is the main identifier.

Following the YAGNI principle, I think we should defer implementation on this until other parts of the server are more complete.

[bcolloran]

+1 YAGNI in general, we can revisit this whenever you are ready :-)

[PythonLinks]

+1. I just read all of the issues, this is my favorite one. (After the one I posted of course!)