On Mon, Jun 15, 2009 at 6:59 AM, William Stein <wst...@gmail.com> wrote:
> > On Mon, Jun 15, 2009 at 3:40 PM, Jason Grout<jason-s...@creativetrax.com> > wrote: > > > > William Stein wrote: > >> On Sun, Jun 14, 2009 at 10:16 PM, David Joyner<wdjoy...@gmail.com> > wrote: > >>> Excellent! > >>> > >>> Once/if you get Sage running on it, will students of mine (<100 total) > >>> be able to use it > >>> and share their assignments with me? > >> > >> 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. 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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---