Hi Brian, <br><br>thanks to you and Matthew for kicking off this discussion. It is something I am interested in as well. I have looked into the codebase as well, thinking about customizing it, and ran into the same conclusions. <br>
<br>Brian, do you have any (tentative, approximate) timeline for those efforts?<br><br>Thanks to all for building these awesome tools. <br>Jonathan<br><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 1:38 PM, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Apr 10, 2012 at 5:41 AM, Matthew Turk &lt;<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>&gt; wrote:<br>

&gt; Hi Brian,<br>
&gt;<br>
&gt; Thanks for your reply.  Over the last couple days I&#39;ve spent some time<br>
&gt; investigating, and I was able to make this work with minimal changes<br>
&gt; -- in advance of going any further, seeing as this is on your radar, I<br>
&gt; wanted to reply with what I&#39;ve found to see if it fits in with your<br>
&gt; vision, or if I should scrap it.<br>
<br>
</div>OK great.<br>
<div><div class="h5"><br>
&gt; On Mon, Apr 9, 2012 at 6:21 PM, Brian Granger &lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Matthew,<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Apr 4, 2012 at 3:46 PM, Matthew Turk &lt;<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; Hi there,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; After something of a protracted discussion on Fernando&#39;s Google+<br>
&gt;&gt;&gt; stream about embedding the IPython notebook, I started digging into<br>
&gt;&gt;&gt; the notebook manager code.  As something of an introduction, I&#39;m<br>
&gt;&gt;&gt; relatively new to this aspect of IPython, but I work on a project (<br>
&gt;&gt;&gt; <a href="http://yt-project.org" target="_blank">yt-project.org</a> ) that currently has a web GUI with a<br>
&gt;&gt;&gt; (execution-blocking, much less fancy, somewhat clunky) web notebook.<br>
&gt;&gt;&gt; On top of this we&#39;ve built a number of display widgets, which really<br>
&gt;&gt;&gt; are what we spend the most time on and what we&#39;re most proud of, but<br>
&gt;&gt;&gt; more importantly they&#39;re what we want to focus our development energy<br>
&gt;&gt;&gt; on moving forward.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Anyway, this is a long way around of saying we&#39;re looking really hard<br>
&gt;&gt;&gt; at ditching our current cell-REPL system and instead building in the<br>
&gt;&gt;&gt; IPython notebook, since it&#39;s awesome.  I&#39;m trying to come up to speed<br>
&gt;&gt;&gt; with how the web notebook works, and I have a couple questions about<br>
&gt;&gt;&gt; the broad feasibility.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; To embed as is, it looks like (as shown with NINJA-ide) one can embed<br>
&gt;&gt;&gt; an iframe to link to a running notebook server.  But rather than doing<br>
&gt;&gt;&gt; something precisely like that, since we&#39;re looking at providing<br>
&gt;&gt;&gt; additional items such as widgets (although Fernando mentioned that<br>
&gt;&gt;&gt; interoperation with callbacks is still underway) is it possible to<br>
&gt;&gt;&gt; extend the templates from the API?<br>
&gt;&gt;<br>
&gt;&gt; Right now the answer is no.  We are currently using tornado as the<br>
&gt;&gt; templating library and it doesn&#39;t support loading templates from<br>
&gt;&gt; multiple directories.  However, we have plans to switch over the<br>
&gt;&gt; jinja2, which supports this fine.  As part of that change we will also<br>
&gt;&gt; be reorganizing the templates and javascript code to make it much<br>
&gt;&gt; easier for people to customize things and reuse things as part of<br>
&gt;&gt; their own web apps.  This is relatively high on my list of things<br>
&gt;&gt; todo, but still might take a while to get to.  Part of the problem is<br>
&gt;&gt; that this stuff is significant enough that it has to wait until after<br>
&gt;&gt; the 0.13.<br>
&gt;<br>
&gt; The change to Jinja2 for the multiple template directories makes sense<br>
&gt; (although the additional C dependency, with possible pure python<br>
&gt; fallback, is a tradeoff), although after looking into how<br>
&gt; RequestHandler is implemented it seems that subclassing handles this<br>
&gt; very nicely.<br>
<br>
</div></div>Yes, jinja2 is a non-trivial dep, but I think we need this power moving forward.<br>
<div><div class="h5"><br>
&gt;&gt;<br>
&gt;&gt;&gt; Inside IPython/frontend/html/handlers.py, the render methods are code<br>
&gt;&gt;&gt; with calls to specific template names, which then render out HTML<br>
&gt;&gt;&gt; templates from a path that can be overridden with settings_override.<br>
&gt;&gt;&gt; I *think* from reading the tornado docs that template_path has to be a<br>
&gt;&gt;&gt; single string and not an iterable of strings,<br>
&gt;&gt;<br>
&gt;&gt; Yes, and this is exactly the weakness of tornado&#39;s template renderer<br>
&gt;&gt; and why we are moving away from it.<br>
&gt;&gt;<br>
&gt;&gt;&gt;and the handlers<br>
&gt;&gt;&gt; themselves are enumerated as classes in the NotebookWebApplication<br>
&gt;&gt;&gt; handlers.  It was when I got this deep that I started to wonder if<br>
&gt;&gt;&gt; perhaps there was an obvious, more straightforward way that I was<br>
&gt;&gt;&gt; missing; if not, I&#39;m definitely willing to do what I can to dive in<br>
&gt;&gt;&gt; and contribute, if embedding is something of interest to the<br>
&gt;&gt;&gt; community, too.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If we take as a given that an IPython engine is currently running,<br>
&gt;&gt;&gt; what would the best route toward embedding a view -- that doesn&#39;t<br>
&gt;&gt;&gt; fully duplicate the contents of static/ and templates/ -- into that<br>
&gt;&gt;&gt; engine?<br>
&gt;&gt;<br>
&gt;&gt; Today there is not easy way of doing this.  You would basically have<br>
&gt;&gt; to duplicate everything.  After the refactoring, it should be much<br>
&gt;&gt; easier.<br>
&gt;<br>
&gt; What I was able to implement, without the additional dependency of<br>
&gt; Jinja2, was a single-notebook embedded instance with default and<br>
&gt; sub-default handlers, allowing for the two basically independent web<br>
&gt; apps to be served by the same tornado instance.  However, it required<br>
&gt; a handful of changes to the IPython source which I&#39;ve put into a<br>
&gt; (readily-destroyable) fork on github under my username MatthewTurk.  I<br>
&gt; attempted to comply with the coding practices in the file and in the<br>
&gt; IPython developer guide.<br>
&gt;<br>
&gt; It accomplished this with a couple main changes to the IPython<br>
&gt; codebase.  The main weakness remains that the HTML fragment that<br>
&gt; specifically corresponds to the notebook components is not<br>
&gt; customizable, but it also allows the embedding user to access the<br>
&gt; IPython components, so setting up their own full HTML fragment should<br>
&gt; also work.  This is accomplished through:<br>
&gt;<br>
&gt; 1) Adding EmbeddedNotebookApp and EmbeddedNotebookWebApplication<br>
&gt; classes.  These subclass the appropriate classes in the existing<br>
&gt; implementation.  Both expose a subset of functionality (for instance,<br>
&gt; no notebook manager), but most importantly the<br>
&gt; EmbeddedNotebookWebApplication accepts an additional_handlers<br>
&gt; argument.  These additional handlers will not be prepended with the<br>
&gt; base_project_url.<br>
&gt; 2) page.html has been modified to have {%%} blocks around every<br>
&gt; component of the HTML.  This allows the initial and final HTML tags to<br>
&gt; be stripped, along with body, script, etc.  embedded_notebook.html<br>
&gt; subclasses notebook.html and overrides these tags, so that using<br>
&gt; ExtJS&#39;s autoLoad functionality we can load it as a snippet (served by<br>
&gt; Tornado) and insert it directly into an existing DOM.<br>
&gt; 3) To accommodate our existing widgets, I extended<br>
&gt; IPython.Notebook.prototype with an external_handlers attribute.  Any<br>
&gt; payloads that come through with the type &quot;external_payload&quot; will get<br>
&gt; passed through to any callback that has been registered with the<br>
&gt; content[&#39;payload_type&#39;].<br>
&gt;<br>
&gt; Setting up an embedded application is then just a matter of creating a<br>
&gt; set of handlers which are fed in as additional_handlers to an instance<br>
&gt; of EmbeddedNotebookApp.  Passing through the new notebook ID was<br>
&gt; somewhat tricky, but disallowing access to the notebook manager and<br>
&gt; redirecting from the base URL /notebook (not<br>
&gt; base_project_url/notebook) to the correct notebook worked around that.<br>
<br>
</div></div>&gt;From what I can tell, this approach sounds reasonable for your usage<br>
case and the present condition of the IPython code base.  I don&#39;t<br>
think these changes are appropriate to go into IPython properly,<br>
especially given the fact that all of this code will be refactored in<br>
a non-compatible manner.<br>
<br>
I can say a bit more about our vision of what the code base will look<br>
like after refactoring:<br>
<br>
* Each page in the web application will have its own directory.<br>
* Each web service will also have its own directory.<br>
* Each directory will have its own template, javascript and handlers.<br>
* Users who want to build a custom app will need to:<br>
   - write their main program (the equivalent of notebookapp.py) that<br>
pull in all the right handlers and templates (possibly their own<br>
subclassed templates).<br>
  - subclass any handlers<br>
  - specify their own url scheme.<br>
<br>
What I don&#39;t think is reasonable is for the main IPython notebook app<br>
to be a super customizable meta app that covers everyones usage cases.<br>
 I am strongly -1 on that.  Our philosophy is to give developers well<br>
isolated components they can use to build whatever they want.  The<br>
range of options developers will want is simply too broad to try and<br>
cover them all from a single main program.  Even in IPython, it is<br>
likely we will have different versions of the main program that<br>
configure the notebook in different ways.  If we build the components<br>
well, it will be relatively straightforward to build custom apps using<br>
them.<br>
<div class="im"><br>
&gt; While these changes worked for me to get something going to prototype<br>
&gt; and experiment with layout inside our app, I understand that they may<br>
&gt; not fit into the broader vision for the HTML notebook.  If they are of<br>
&gt; some use I would be more than happy to work on them until they are up<br>
&gt; to the quality necessary for contribution.  In my conversations with<br>
&gt; Fernando the interest of the IPython development community in<br>
&gt; collaborating with other sub-communities in scientific python has been<br>
&gt; pretty clear, and I would like to do what I can to help with this<br>
&gt; effort.<br>
<br>
</div>We absolutely want to build collaborations with other communities.  In<br>
this case, I think we need to just get the refactoring done and have<br>
you try it out as we do the work so we make sure it will work well for<br>
your usage cases.<br>
<br>
The tricky bit is that 1) we have to wait until post 0.13 and 2) the<br>
changes to the codebase will be so significant that all other<br>
development on the notebook will have to be frozen.  Because the<br>
notebook is going to be the foundation of so many things, it is really<br>
important that we develop a solid architecture from the beginning, and<br>
that takes time.  But, in our experience, it is well worth it in the<br>
long run.  It just means things move more slowly at times.  Hope you<br>
can be patient :)<br>
<div class="im"><br>
<br>
&gt;&gt;<br>
&gt;&gt;&gt;  Would prepending an additional path to the base_project_url<br>
&gt;&gt;&gt; work, so that any calls to/from the engine would require that<br>
&gt;&gt;&gt; base_project_url?  And then, post-instantiation, appending new<br>
&gt;&gt;&gt; handlers to the NotebookWebApplication, for the &quot;embedding&quot; app&#39;s<br>
&gt;&gt;&gt; templates, which perhaps have to be rendered from strings?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Any ideas would be greatly appreciated, and again, thanks for all your<br>
&gt;&gt;&gt; hard work on IPython.<br>
&gt;&gt;<br>
&gt;&gt; Unfortunately, for now I think the best answer is to wait.  We will<br>
&gt;&gt; try our best to get to this ASAP though.<br>
&gt;<br>
&gt; Ah, I guess I missed that there&#39;s a refactor coming.  I will dig<br>
&gt; further through the IPython-dev archives to try to find out more<br>
&gt; information about this before we modify any of our code to comply with<br>
&gt; IPython&#39;s current API; most of our users upgrade dependencies<br>
&gt; relatively slowly, so perhaps it is premature for us to start looking<br>
&gt; at interoperation with or utilization of the new 0MQ engine system and<br>
&gt; the HTML notebook.<br>
&gt;<br>
&gt; Again, thanks for your reply, and all of your amazing hard work on IPython.<br>
<br>
</div>Thanks, let&#39;s keep in touch.<br>
<br>
Cheers,<br>
<br>
Brian<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; -Matt<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt;<br>
&gt;&gt; Brian<br>
&gt;&gt;<br>
&gt;&gt;&gt; -Matt<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; IPython-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Brian E. Granger<br>
&gt;&gt; Cal Poly State University, San Luis Obispo<br>
&gt;&gt; <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; IPython-dev mailing list<br>
&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt; _______________________________________________<br>
&gt; IPython-dev mailing list<br>
&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br>
<br>
<br>
--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jonathan Rocher, PhD<br><span style="color:rgb(102,102,102)">Scientific software developer</span><br><font color="#888888"><span>Enthought</span>, Inc.<br>
<a href="mailto:jrocher@enthought.com" target="_blank">jrocher@<span>enthought</span>.com</a><br>
1-512-536-1057<br>
<a href="http://www.enthought.com/" target="_blank">http://www.<span>enthought</span>.com</a></font><br><div style="display:inline"></div><br>