Hi Dorian! On Tue, Jul 21, 2009 at 1:11 PM, Dorian Raymer<deldo...@gmail.com> wrote: > Hi Ondrej, > > I like what you have done! > > On Tue, Jul 21, 2009 at 10:21 AM, Ondrej Certik <ond...@certik.cz> wrote: >> >> On Tue, Jul 21, 2009 at 10:44 AM, William Stein<wst...@gmail.com> wrote: >> > >> > On Tue, Jul 21, 2009 at 9:39 AM, Ondrej Certik<ond...@certik.cz> wrote: >> >> >> >> On Tue, Jul 21, 2009 at 1:58 AM, Robert >> >> Bradshaw<rober...@math.washington.edu> wrote: >> >>> >> >>> On Jul 20, 2009, at 9:02 PM, Ondrej Certik wrote: >> >> >> >>>> Well, let me say that I really like to run things on the appengine, >> >>>> rather than to constantly maintain our own servers. I see no reason >> >>>> why the notebook cannot run on the appengine, only the AJAX would >> >>>> talk >> >>>> to our own server with Sage to actually evaluate the cells (and for >> >>>> many people, I think appengine itself could actually be enough). I >> >>>> have to think though what the best way to transfer data to the >> >>>> database with worksheets is though. >> >>> >> >>> +1, though for Sage we rely heavily on compiled code. I wonder how >> >>> much introduced latency there would be if the backend were served on >> >>> a university computer, and the front end in appengine. >> >> >> >> I think none, it would be as fast as it is now (e.g. the browser >> >> communicating directly with the engine). >> > >> > How is it "none", given that there are now three separate computers >> > involved instead of two? There would have to be a little extra >> >> What I meant is that the latency in typing 1+1 into the cell and get >> the output cell saying 2 should not change at all, because the >> javascript in the browser sends a POST request to the Sage engine >> (e.g. a web app with the url interface, just like it is now) and it >> returns it back directly to the browser. >> >> What changes is the database storage, e.g. either the javascript in >> the browser, once it receives the output of the cells also sends it to >> the appengine (or whenever the database is running), or the engine >> sends it itself, I don't know yet which approach is better. So there >> are some issues involved, like if one of those connections fail etc. >> But as long as both connections are up and running, the user would not >> recognize anything at all. >> >> > latency, i.e., whatever there is between appengine and the "sage >> > engine". That said, the internet is pretty fast these days :-). And >> > the scalability of a decoupled approach like we're talking about is a >> > big plus, if it works. >> >> Right, it has to be tried to see if it works. But I think it's worthy. > > > This is very cool. The "notebook" is really the encapsulation of at least > three different projects. > - A formal api interface to the Python or Sage interpreter (and that > implementation of the interface for each of those systems) > - Some kind of canonical and portable persistent notebook format (and > something to manage all your notebooks) > - The front end client (javascript/html/css) that is the notebook you > actually use (really, a source code/text editor of which many projects > simply trying to do this right (in the browser) exist) > > In terms of distributing the components/responsibilities of the different > parts (like what you are talking about with the AJAX computation requests to > the sage server being different from the appengine frontend hosting, and > then somehow integrating a possible third database element distinct from app > engine (something I definitely want, because I want to own my data!!)), > codenodes design is centered around this and has many cool > (improving/improvable) solutions. > > Although our current use case with app engine is a different permutation, as > we are delegating all computation requests to it and keeping the data and > frontend on our own server, the architecture is getting there to be able to > do any permutation that makes sense. > I have been working on improving the backend and have recently made some > great progress: > http://github.com/deldotdr/codenode/commit/5a9ed5a19e0f71c48d8f62bb206f8b1aa347d1d6 > > Some of the key highlights: > - I want it to be trivial to add different backend engines as Plugins. This > means things like Sage, and other non-python interpreters. There are a > handful of major configuration items: path to interpreter bin, args, > environment variables (the hardest part/most work for sage), and run path. > > - frontend is able to know about multiple different backends (like app > engine, a sage server, or another privately hosted server), each of those > possibly having different engine plugins (i.e. Python and Sage at least). > > - clear decoupling of the communication lines for administering all user > data and backend permissions, getting/saving notebook data to a database, > evaluating/tab completing/etc. code on an interpreter process. > > It would be great to get feedback on this new stuff as I integrate it into > the full system. There are a lot of design decisions in the same vein as > your questions of the right way to separate the AJAX computation requests > from saving to the database, etc. > > >> >> > >> > By the way, if you haven't already, I personally think you should >> > start a mailing list, web page, trac, etc. for a separate notebook >> > project, since you're already writing code. There's already some >> > confusion about where we are supposed to have this discussion -- and a >> > funny mix of sage-devel and codenode doesn't seem right. >> >> Well, I hope codenode guys could pick this up and they would be the >> notebook. I unfortunately probably can't spend too much time on this, >> until september. But I wanted to get this going to see which approach >> to take. > > Cool! With codenode, we have strived to make the major components as > decoupled as possible such that people can hack on any one of them (mostly) > independent of the others. Like you, we really want to work on it all the > time, full time, but we also have real jobs and other projects that take up > our time. I think collaborating would be the best thing that could happen > for the project and the evolution of the notebook. > > We have put in significant effort in thought and code writing and, although > it has not been very obviously presented in the past, we have the foundation > for something that we strongly want to be the basis of the effort you are in > the midst of now. We have been through the process you are in, and hopefully > a fresh review of our source code (especially the javascript and the backend > design) will resonate with your current thought process. > >> >> I wrote the above in about 2 days (roughly), but it's only the first >> 90%, e.g. the cells sort of works, but the rest 10%, like tab >> completion, worksheets, saving. loading, publishing, users, fixing it >> so that it works 100% in all browsers..... That would take a lot more, >> and I can't do it yet. But I hope it's encouraging to all of you to >> learn some AJAX too till September, so that we can work on this >> together. :) > > ;-) Yes, it takes *a lot* more. A quick review of what codenode has sitting > there already: > > - Generalized notion of a cell in the notebook. Cells can contain anything, > even more cells! This is great for handling different output cells (text, > traceback, plots), different input formats, and doing col things like > Mathematica does with nested sections -- maybe that is too much, but when > used in the simplest case, it gets the job done smoothly. We have a cell id > scheme worked out that allows any arbitrary addition, deletion, and > rearrangement of cells. > > - Tab completer, decoupled from cell evaluation. This has it's own > javascript source code file, Completer.js > > - Event Delegation and pretty simple (definitely refine-able) configuration > of key + mouse combination event handling. This doesn't use the jQuery > plugin yet, but it works great and shows how far down the path we have > already gotten. > > > The sage notebook and codenode represent two extremes in design > ideology/practicality, but they both already have great usable functionality > supported by untold man hours of hard work and thought. > I think a lot of progress on a great generally usable notebook can be made > with the help and drive of a third perspective like your own [Ondrej]. > > There is too much work remaining, work ranging from realizing un-implemented > big features to last mile refinements, not to mention reconciling the > awesome but coupled features of the sage notebook (plotting, interact, etc) > into your (and codenode's) more general and decoupled model. > > So, I am all for combining efforts and becoming more in tune with your end > goal and motivation for improving the notebook.
I agree with everything you wrote. Only one suggestion -- could you take my simple frontend for the cells and incorporate it in codenode? I mean how things *look* like, so that it looks like the Sage notebook. The default codenode look & feel doesn't work well in my browser, since I can't figure out where to click to find the cell, the cursor changes in some weird way and generally it's confusing to me etc. So that's a major problem, but the fix is really easy, just change the bit of the javascript + CSS styles and it will look like Sage. There could be some option to choose between the two designs if you prefer the current codenode style. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
