Nissim,
Hi, glad to see you thinking about these issues, we are definitely
interested in them. There is actually a lot going on with this
stuff...
> I'm new here and I wanted to run this by the group before I start working on
> it. I'm interested in building a facility to use the notebook to edit and
> execute javascript code for presenting data from the python kernel. I know
> there is a magic function and there is some sort of way to have python code
> render js in <script> tags, and you can put javascript in the Markdown
> cells, but I was envisioning something more like a standard codecell, but
> execution is handled by the browser rather than the kernel.
For security reasons, we are going to disable all user written
JavaScript in the notebook. As the notebook is used in more and more
multiuser settings, it is too dangerous to run JavaScript in a context
that basically gives the browser full shell access to that users
assets.
> Let's say you've loaded some data and run some computations in your python
> kernel and now you want to display results in the notebook using some
> javascript library like d3, datatables or processing. If you want to do
> this by writing the javascript code in a CodeCell and evaluating that code
> in the browser you need a couple of things:
For something like this, we are already working on a JavaScript plugin
system that will enable people to write this JavaScript and load it
into the notebook server before it starts. Here is the PR that
implements this:
https://github.com/ipython/ipython/pull/2518
This is still very much a work in progress, so we would love feedback.
> 1) ability to change a code cell language to javascipt in the notebook
> frontend. I saw that there is a language field in the notebook file format
> for CodeCell but it is always = python.
We don't want to allow notebooks that mix different languages at the
CodeCell level. It introduces too many complications. However, we do
want to create a JavaScript based kernel that would allow you to
create an entire JavaScript based notebook. However, we don't know
how to handle that in a secure manner, so the work is stalled (in
addition to not having anyone that is pushing on it - maybe that will
be you ;) ).
> 2) facility to have the browser JavaScript engine evaluate the contents of
> the javascript CodeCell when it is executed by the user
This is possible, but again the security is the crux we have to solve.
> 3) http REST api that will return json representations of Python objects
> that exist in the kernel. (this may already exist, I don't really
> understand the kernel communication protocol yet).
This is already implemented in the PR that I link to above.
> There are probably some more things like the ability to add CSS, HTML, js
> and image resources to the server that it can then serve back to the client.
> I see that there's been a lot of discussion related to this in the plugins
> thread, but maybe there can also be a method for accessing resources from
> the network and then telling the notebook server to serve them from some
> path.
This is exactly what the JavaScript plugin idea above adds. We even
have a d3 example.
> I'd like to implement this and I had a couple of questions:
>> 1) Does this fit in with your ideas for the notebook or is editing non
> python code in CodeCell outside of the vision?
Yes, we want the notebook to support other languages.
> 2) Should there be another Dropdown for the language of the CodeCell or
> should there be a javascript option added to the existing select box.
No, at this point we want each notebook to be tied to a kernel in a
single language. What this means is that as we add kernels in other
languages (this is already happening) we will add a UI for selecting
the language of the notebook upon creation. But this has to be done
at notebook creation time when the kernel is created. IOW, it won't
be possible to *change* the language of a notebook once it is started.
But again, the core problem with the JavaScript kernel is one if
security. There was some talk of working with Mozilla on this, but
that has stalled for now.
For now, I would say that the best thing to do is to help us review
and test the JavaScript plugin PR above. That will be the first
method of getting better JavaScript support in the notebook.
Cheers,
Brian
> Thanks
>> -Nissim
>>> _______________________________________________
> IPython-dev mailing list
>IPython-dev@scipy.org>http://mail.scipy.org/mailman/listinfo/ipython-dev>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com