Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
Although I'm not active on MO, I think that's a great idea. You wouldn't need a separate Sage Cell Server, actually (that's the point of Cell really). However, a separate server might be preferred for speed and reliability.
Much like MathJax, Sage really only needs a javascript call, so no major changes to the SE software should be needed (though probably a few minor ones to integrate the output). In fact, you could probably write a MathJax extension to wrap it all in one.
Here's a link to the Sage Cell server about page.
You can't use a script tag in posts. Is there another way?
If you do it right, you wouldn't need a script tag in the post. I'm guessing you looked at the about page? That seems to be written more with raw html authoring in mind. Since you enter text via the MO input field, you'd just write something like \begin{sage}\end{sage} which then gets turned into script tags when inserted in the page.
That should work since that happens after the software strips bad html tags. It's worth a shot; I'll ping Anton and Scott.
Based on a quick look, this seems doable, and it certainly would be cool. There are a few concerns that come to mind:
(0) Let's make sure we don't send a ton of traffic to some sage cell without it expecting us.
(1) Support. If the ground moved underneath us, it would be good to know that lots of posts won't become unreadable. I'm not too worried about this because not too many posts are likely to use the new functionality, and the ground isn't likely to move much.
(2) Security. Sticking user content into script tags raises a huge red flag. I'd like to be really sure that nobody could do something malicious. It's probably okay to trust the sage cell operators, but definitely not okay to trust everybody on the internet.
re (0) very much so. The Sage Cell server is pretty slow as is. See my earlier comment.
re (1) Sage has been NSF supported for a while and is managed by an independent foundation.
re (2) Two reasons not to worry: a) Sage works server side so any code gets sent to Sage as pure text and is interpreted there and sent back. b) the text should be sanitized into pure text coming from the MO input anyway (not sure if sage would have problems with that)
@peter re (1). I am not worried about Sage folding but they could do something as simple as change the URL to break the scripts here. Relying on an outside resource is always brittle.
Re: (0) and (1), we could run our own server on an Amazon EC2 computer. This costs money [1], but not a huge amount, and it would be pretty cool.
(2) is indeed a big worry. Peter's reasons are reasons to worry less, but sticking user content in script tags is so terrifying you have to have more than a list of reasons not to worry. :-)
[1] (At the barest minimum, about $30/year, for an anemic processor that would be worthless to us. I'd guess for a few hundred a year we could run something usable, but I don't have a good way to estimate how much CPU a Sage Cell server really warrants.)
Peter just emailed me a link to this discussion. I started (and continue to maintain) the Sage cell server project. I've got to run, but here's a quick response to the three points raised:
(0) We are ramping up the infrastructure soon to multiple servers. We've been running it on a single (but pretty high-end) server. We're moving to 4 virtual servers for fault-tolerance and load balancing. However, if (and before) this became official on MO, I'd feel better asking William Stein (owner of the servers, and the guy who started Sage) if it's all right to use his computers (if that's what you want to do).
(1) You could always set up a server that proxies requests to the cell server. For example, you could set up HAProxy to transparently reverse proxy requests, and at MO just use something like sagecell.mathoverflow.net. If our server goes down, you could redirect to a different server. Or you could set up your own server, of course. You'll also have the sage code, so you could set up something so that if for some reason the sage cell server isn't available, the page could still render the code as plain text.
(2) On the sage cell server, a user could do something like this and thereby embed whatever javascript they wanted into the page. You could prevent that by sanitizing the html that comes back from the Sage server, of course.
1 to 11 of 11