[IPython-dev] Separating the notebook from the file manager+text editor+terminal

[Brian Granger]

I am simultaneously +1 and -1 :)

+1: anything that helps us to write better, more modular code is a
huge improvement. As we add the terminal and text editor to the
notebook, we will have a great chance to improve these abstractions. I
think this will also help us to develop abstractions that enable our
different components to be reused in different contexts. I like that
and think it is important. Having separate repos for these components
*may* even make sense, although I wouldn't start there.

-1: I am have always been, and remain, opposed to turning our main
notebook app into a general web server project that can load and run
arbitrary combination of components. I think our notebook server
should run a fixed and consistent set of components for all users.
Anything different should be a "new app", not merely the same app
reconfigured.

Timing: I think the best way to proceed is to start developing the
terminal and text editor and see what abstractions start to develop
for these N=3 and N=4 cases

Dashboard: I too want to push back on the dashboard becoming a full
blown file manager. I am also opposed to there being multiple
dashboard that we maintain and which our users can choose between. I
think this is not a situation where we want to "settle disagreement by
making no decision and providing configuration instead." At the same
time, we are going to have to support more operations than we
currently do. The best model for balancing these concerns that I have
seen is the github UI. It basically has our UI, with a few extra
things for moving files around. I think we should aim for something
like that.


On Wed, Aug 13, 2014 at 1:26 PM, MinRK <benjaminrk at gmail.com> wrote:
> I think this sounds like a good plan. I’m not 100% sure how to go about
> implementing it, though. It would require that our webapp code be a bit more
> modular. We took some steps in that direction with 2.0 - Brian and Zach
> moved each component into discrete subpackages and URL areas, and are loaded
> with a single call to load_handlers. We could extend this a bit further to
> something like load_component, and figure out a way to configure / register
> available components.
>
> -MinRK
>
>
>
> On Sun, Aug 10, 2014 at 5:22 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>
>> We've often said that, for people accessing the notebook on a remote
>> server, we need to provide certain basic utilities - like the dashboard,
>> which is now under pressure to evolve into a file manager, and an in-browser
>> terminal and text editor, both of which we intend to add to the notebook.
>>
>> I propose that we separate development and packaging of the notebook from
>> the project to assemble this trio. The new project would live under the
>> Jupyter org, and be called something like 'utility-apps'. I see several
>> advantages of this:
>>
>> - A different crowd of developers may be attracted to work on that,
>> without having to know anything about the internals of IPython's machinery
>> for handling and executing code. For instance, I'm pushing back on turning
>> the dashboard into a full blown file manager, because I think that adds a
>> lot of extra complexity in a codebase that's already complex, but if it was
>> a separate project, it could grow into a file manager without being a
>> problem.
>> - People running the notebook locally may want to install just the
>> notebook component, and not poor web-based clones of applications which they
>> have well developed equivalents for already installed.
>> - There are lots of potential users of the file manager/text
>> editor/terminal trio who probably wouldn't use the notebook: for instance,
>> it could be a basic admin interface to any server.
>> - It could become a base on which people could write other HTML
>> applications to meet their own needs. Following our usual MO, I wouldn't try
>> to design it like this straight away, but keep it in mind, and evolve the
>> APIs as things mature.
>>
>> There are still plenty of questions to be answered. How would this new
>> component interface with the notebook server? What would the notebook look
>> like without the file manager installed? But these could certainly be worked
>> out, and I think they're worth working out in order to keep the scope of the
>> notebook project in check.
>>
>> Thomas
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com