On Tue, Jun 16, 2009 at 4:30 AM, Alex Clemesha<cleme...@gmail.com> wrote: > >>> >>> >> >>> >> You can't run Sage on the Google Ap Engine. >>> > >>> > Couldn't you have a Google App Engine application call the simple http >>> > api to make some public notebook somewhere perform calculations? I'm >>> > thinking of something like the remote sagetex that Dan announced the >>> > other day. I'm not sure if this would make anything better (I'm not >>> > even sure why Google App Engine is so important), but using the simple >>> > http api might help somewhere. >>> >>> I can't imagine that would do anything but make things worse. It >>> would simply introduce an extra layer of complexity and probably just >>> increase the chances that things would break and feel slower, while >>> probably reducing security. I see no win to this approach for >>> anybody at all. Please correct me if I'm wrong (since then I would >>> learn something). >> >> You are right, an App Engine app utilizing some other Sage notebook server >> wouldn't provide much benefit unless you want to take advantage of google's >> Users Service, Datastore, etc. (I am not currently using those services) >> >> To reiterate the subject of Ondrej's thread, the benefit of running a >> notebook _on_ App Engine is that security is google's problem! >> >> App Engine is a computational sandbox for notebook processes. The risk of >> offering a public notebook in terms of OS/Network security is dramatically >> reduced when arbitrary code run by public users is _not_ executed by your >> (the deployer's) machines. >> The cost of this free security is stifled freedom in what python packages >> you can install (AppEngine imposes steep restrictions). This isn't so bad >> though -- packages like sympy work on App Engine (and sympy is now installed >> on live.codenode!), but Sage, unfortunately, does not work (yet? maybe one >> day, google...). >> >> Ondrej asked if our whole live.codenode.org app was on App Engine, and the >> answer is: No, only the backend computation of each notebook is on App >> Engine. The frontend runs on our own servers. > > Just to add a little to this, the backend (kernel == where notebook "engine" > processes run) is a totally > different process designed to be connected to over a network. > > We are intent on making the frontend and backend as decoupled as possible - > although this is harder and more time consuming in > the short-term, you win in the long-term because once things are in place, > you can just "plug in" > different backends, running elsewhere on the internet, as is the case with > App Engine. > > One final important point is that for just simple local usage, there's a > command line utility, "codenode-admin", > that wraps the starting up of the frontend and a local backend, making it > easy to use locally. More work > on "codenode-admin" needs to be done for it to do lot's of useful things, > but the basics are in place. > > The frontend process is basically a Django instance (plus some twisted.web) > that handles the templates, > urls, authentication, interacts with the database, etc. This is the one > running on our servers.
Thanks for thorough explanations. I have a question --- why don't you run the frontend on the app engine as well? That way, you don't need any servers and just leave everything to Google to handle. 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 -~----------~----~----~----~------~----~------~--~---
