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<http://github.com/codenode/codenode/blob/08f33199464ca197dd8020f73846d5d431dc594f/codenode/frontend/static/js/Cell.js>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<http://github.com/codenode/codenode/blob/08f33199464ca197dd8020f73846d5d431dc594f/codenode/frontend/static/js/TreeBranch.js>-- 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<http://github.com/codenode/codenode/blob/08f33199464ca197dd8020f73846d5d431dc594f/codenode/frontend/static/js/Completer.js> - Event Delegation<http://github.com/codenode/codenode/blob/08f33199464ca197dd8020f73846d5d431dc594f/codenode/frontend/static/js/Delegator.js>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. -Dorian > There is one more thing I want to try -- pyjamas, as pointed out > above. I already played with it yesterday, and what I saw so far is > *impressive*. So my next step will be to rewrite what I did into > pyjamas (e.g. just pure python both on the server and in the browser). > If that works and I think it could, well, that would be the way to go, > since I could debug all those functions like for calculating cursor > positions etc. in Python. > > 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 -~----------~----~----~----~------~----~------~--~---
