A way to register a directory to be served statically

[shashi]

If one is using HTML imports, a file x.html can import y.html so reading in x.html using display will not be sufficient (it will lead to a 404 when it tries to load y.html). One could use a tool to concatenate all of them together though but that is not so ideal when you want to import things as you need them interactively. It would be nice to have them served from disk and loaded as and when required by displaying some Javascript for it.

I think a proper solution to this would involve some way for notebook code to register a directory to be served in a static URL location - again this seems like a feature that Jupyter will need to make possible.

I know that it is possible to serve files statically from files/ wrt the current directory, but I think this feature is different from that - specifically, it would be much nicer if packages can set this up automatically and transparently when loaded inside IJulia.

Ref: JuliaLang/IJulia.jl#339

[Carreau]

You are hitting one of the problem we have for a long time now.
How do you do that if server and kernel are on different machines ?
How do you deal with that on upgrade ?
How do you allow different kernel to expose differents file ?

We lack manpower to tackle these kind of issues, and actual people that have experience in javascript, and actual use case. We would be happy to discuss the need and constraint.

[shashi]

How do you do that if server and kernel are on different machines ?

Oh wow, I didn't know that's possible. What about just letting this work for the others who have kernel and server on the same machine and throwing a warning otherwise?

How do you deal with that on upgrade ?

When the package registering the static directory upgrades, it can also serve new files right? Was that the question?

How do you allow different kernel to expose differents file ?

That's a good point. I think one could have a message where the kernel sends Jupyter a request to serve a directory / a file and Jupyter returns a URL of the form /kernel_static/<UUID> where the static files get served from.

We lack manpower to tackle these kind of issues, and actual people that have experience in javascript, and actual use case.

We do have an actual use case (see the IJulia issue referenced above). And I think between @rohitvarkey and I we can figure out how to do this if everyone agrees on a design.

[gnestor]

@shashi Any update on this one? Can we close?

[shashi]

I'm not sure if there were updates regarding this. I think a good way to do this is via a plugin...

[akloster]

I have run into this issue also a couple of times. Some of this can be stated as the general problem of transferring data to the browser.

For individual kernels:

• images can be transferred as data URIs
• comm messages can be used, with or without messages. The drawback is that binary data has to be escaped and coded to fit into the "json over websocket" paradigm
• The kernel can output html/javascript code which then can be executed or picked up by the front-side code. Same problem about encoding, and additionally the kernel can't really control where in the notebook the output is going.
• Use Tornado or Asyncio to run your own server, optionally in another thread. No encoding problems, can implement any REST API it wants, even additional websockets. The problem here is the additional port that needs to be opened and managed. It's not trivial for the kernel to figure out under which IP address this port is accessible.

In my opinion, using comm messages is the best method, because it requires no additional configuration. Sometimes though, this isn't possible, or very difficult, because certain Javascript APIs aren't flexible enough to take data from other front-side code, or it would be too complicated to convert them from a REST API.

A notebook extension could act as a reverse proxy to the kernel's HTTP server. The notebook server would provide a URL base and forward the requests. This would solve problems about ports and addresses. It would be tricky to support advanced HTTP features like websockets or audio/video streaming, but these would also be possible.