Replace tmpnb.org with links to mybinder.org

[minrk]

Right now, we are running try.jupyter.org (tmpnb.org) with the massive docker image containing Python, R, Julia, Haskell, etc. here. The main reason we have this kitchen-sink image is that tmpnb only runs with one image. With mybinder.org, a collection of links to different binders can solve this problem without having to run a dedicated service

Problems right now:

• deploying tmpnb instances is a bit of a pain
• we have one massive image to update
• I might be the only person keeping tmpnb.org alive

Potential downsides with switching to binder:

• Binder has its own infrastructure and hosting costs. Currently, tmpnb.org has ~200 concurrent users at any given time. If all of these folks moved over to mybinder.org, this would ~double the total binder traffic. It may not be appropriate for Jupyter as a whole to burden binder with this cost.

Proposal

My proposal is to switch try.jupyter.org to a collection of binderable repos, demoing basic functionality and retire docker-demo-images (jupyter/demo) entirely.

Steps:

1. build a few demo repos
2. update try.jupyter.org to redirect to the binder link (OR: serve the landing page), rather than iframing tmpnb.org
3. shutdown or reduce tmpnb.org
4. archive https://github.com/jupyter/docker-demo-images

[terna]

I absolutely agree, I'm a happy my binder user, best, Pietro

[damianavila]

The proposal sounds reasonable to me as well, and I think the pros overpays the cons.

[Carreau]

Agreed, we can also just host a page on try.jupyter.org that list multiple images/languages/kernels. We could also kill 2 birds with one stone in the long run and have a clear list of kernels with a link to each of their respective binders.

[minrk]

Yeah, a landing page with a few links would work as well, rather than a pure redirect to a default binder. That will also mitigate bounce traffic consuming binder resources.

[ellisonbg]

+1

[yuvipanda]

+1 binder should be able to support it!

[rgbkrk]

Awesome.