> >> >> >> >> 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<http://code.google.com/appengine/docs/python/gettingstarted/usingusers.html>, > 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. -Alex > > Here is how we setup live.codenode.org: > I extended the Sympy AppEngine CLI example, adding support for tab > completion and solidifying a simple HTTP API, and I deployed this app on my > appengine account. (the code for this app is available in the codenode > repository under examples/) > > I also wrote a version of the codenode kernel/engine client to interface > this HTTP API (available in the latest codenode revision). > The result is the ability to run a codenode frontend anywhere you want, > configuring it to use the backend running on AppEngine. Each notebook gets > it's own namespace and has access to any python modules installed on the > AppEngine account. > > Anyone so inclined can replicate this exact deployment using the latest > revision of codenode and their own AppEngine account. I will follow up with > detailed instructions for this deployment tomorrow night on > knoboo/codenode-devel. > > Please ask clarifying questions if my high level explanation was unclear. > > Thanks, > Dorian > > > >> >> >> --- William >> >> >> > > > > -- Alex Clemesha clemesha.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
