[IPython-dev] IPEP 7: Notebook dependent frontends

[Carl Smith]

On 19 November 2012 17:13, Brian Granger <ellisonbg at gmail.com> wrote:
> Carl,
>
> I think there has been a bit of confusion.  I think the IPEP we need to
> discuss at this point is for adding *native* support in the IPython Notebook
> server for editing other file types using ACE/CodeMirror.  That is, I think
> we want the notebook dashboard to show all file types (not just notebooks)
> and when a user clicks on one of the other file types, they get an editor
> window with that file.  This should be fully integrated with the notebook
> UI+Server and on by default for all users.  I don't think we want to go into
> the direction that you propose of allowing the creation of completely custom
> UIs/Frontends.  The reason is that such UIs will require custom server code
> to support, which raises a whole bunch of issues that we are simply not
> ready to tackle in any way.  Does this make sense?

Ah, OK. Feel free to edit or delete the IPEP if it's not especially
useful as is.

I was intending for these frontends to only use the existing API that
the Notebook uses now, so no server side changes would need to be made
beyond adding one feature. The IPython server would need to be able to
serve any local file as a HTTP response.

If the IPython server API could accept requests to a specified URL,
where the request would contain a path to a file, and the server could
just return that file, then everything should work without any other
changes being made.

A user could save the main HTML file for any web app on the same
machine IPython is running on, then write a magic that outputs some
JS. The JS would open a new tab, pointing the tab at the specified URL
and passing the file's path in the request. The server would return
the file, and the app would be rendered in the new tab. Once the app
is running, it should use the same API as the Notebook uses for all
future interactions with the server/kernel.

You could almost do this now, but you'd need a separate server to
simply serve the panel app's source on each instantiation.

> On this broader issue, the new Javascript plugins under review would provide
> an implementation route for some of what you are talking about (the client
> side, not the server side).

I wasn't aware of this work. Maybe this will handle the problems on
the client-side, which, as I understand it, are only problems of
difficulty, rather than technical limitations.

Thanks Brian