Add dashboarding section

[parente]

Source: https://jupyter.hackpad.com/Spring-2016-Dev-Meeting-h0y1TIAWxz1#:h=Dashboarding

[parente]

@ellisonbg @fperez @bollwyvl @minrk There's an action item to add a URL to the notebook server. I'm not clear on how that would work given there would be two implementations of the dashboard authoring / rendering in the notebook server, one as a classic extension and one in Jupyter Lab. Which would render the output at the URL? Do we want the server dependent on one or the other since they're both, technically, plug-ins?

[parente]

Need feedback on the TODO before merging.

[rgbkrk]

Perhaps we can iterate on the TODO with another PR? Or even delete it?

[parente]

We could, but it's a pretty big question mark in the roadmap to not know what is going to do the actual dashboard rendering in the notebook server.

[rgbkrk]

I'd make the wording allow for any of the approaches outlined to be able to handle it so it doesn't block the rest from coming in from this PR.

[parente]

@rgbkrk rewritten to mark the specific renderer as TBD. Is this cool with others?

To clarify, I don't really care what renders it, I'm just sanity checking that we did agree that something in the notebook server would have this responsibility.

[rgbkrk]

/cc @ellisonbg

[fperez]

Yes, I think we did agree to that :) Implementation specifics TBD, but for sharing/collaboration reasons in some contexts, that seemed like the right way to go and I don't recall any opposition.

[parente]

OK. Then I've got no other outstanding edits. Someone can click the big green button.

[parente]

As @bollwyvl, I and others noodle on the proposal for layout metadata in notebooks (https://jupyter.hackpad.com/Document-Layout-Metadata-infor-Notebooks-pjlprsYHvtw), I'm wondering what the broader community thinks we should be doing with respect to the layout spec:

1. Writing a light spec about where in the notebook document layout tools (dashboards, nbpresent, RISE, ...) should store their metadata to avoid conflicts and enable simple discovery. This can be done quickly and allows anyone to write their own extensions / plugins how they see fit for whatever layout he/she is trying to support (slides, posters, mobile dashboards, ...), but gives no interoperability guarantees.
2. Writing a detailed spec about how all layout tools should adopt a common format for specifying arbitrary layouts with sections, coordinates, dimensions, scaling, viewports, etc. This will enable interoperability across tools if/when a common schema can be designed and implemented across all tools for all use cases and layouts.
3. Both: one then the other?
4. Something else entirely.

[rgbkrk]

In the short term, 1. In the long term 2. I guess that means 3/both.

Solely because 2 may take forever while we can learn how 1 shakes out.

[damianavila]

In the short term, 1. In the long term 2. I guess that means 3/both.

Ditto.
Btw, PR LGTM.

[parente]

We've spec'ed out the current jupyter-incubator/dashboards metadata and rendering requirements here: https://github.com/jupyter-incubator/dashboards/wiki/Dashboard-Metadata-and-Rendering

Next up is the light spec for layout tool metadata as an enhancement proposal.

Any reason not to merge this PR?

[damianavila]

Any reason not to merge this PR?

No reason, I think... it was opened more than 20 days, people offered feedback and we could change things later with another PR (if there is more discussion on this topic to be landed in the roadmap). Merging...