[IPython-dev] IPEP 7: Notebook dependent frontends
Wed Nov 21 02:51:31 CST 2012
On Mon, Nov 19, 2012 at 10:49 AM, Carl Smith <firstname.lastname@example.org> wrote:
> On 19 November 2012 17:13, Brian Granger <email@example.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
> > server for editing other file types using ACE/CodeMirror. That is, I
> > we want the notebook dashboard to show all file types (not just
> > 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
> > the direction that you propose of allowing the creation of completely
> > UIs/Frontends. The reason is that such UIs will require custom server
> > 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.
Wouldn't it be better to add some kind of "rejected" status to the IPEP,
similar to regular Python PEPs? In fact, I find the status part of regular
PEPs to be the most useful part, because it's otherwise not clear if the
PEP was already implemented, or being implemented, or still being
written/discussed, or rejected, or what.
Here's a PEP of the Python PEP guidelines:
http://www.python.org/dev/peps/pep-0001/. It might be useful to emulate
much of that with the IPEPs.
> 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.
> > an implementation route for some of what you are talking about (the
> > 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
> IPython-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev