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. > > 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. 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. :) 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 -~----------~----~----~----~------~----~------~--~---
