-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to register a directory to be served statically #320
Comments
You are hitting one of the problem we have for a long time now. 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. |
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?
When the package registering the static directory upgrades, it can also serve new files right? Was that the question?
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
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. |
@shashi Any update on this one? Can we close? |
I'm not sure if there were updates regarding this. I think a good way to do this is via a plugin... |
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:
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. |
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 bydisplay
ing 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
The text was updated successfully, but these errors were encountered: