On Fri, Feb 22, 2008 at 10:56 AM, David Joyner <[EMAIL PROTECTED]> wrote:
> > On Fri, Feb 22, 2008 at 1:09 PM, Jason Grout > <[EMAIL PROTECTED]> wrote: > > > > Wow, this discussion blew up way to fast for me to keep on top of it > and > > form a coherent opinion. Ted, I'm specifically CCing you; if you don't > > want to reply (either on or off list), I understand. Personally, I'd > > like to keep working on some the issues that I find interesting and I > > think you have already and will yet have a great deal to contribute (if > > you decide to keep working with us, that is). > > > > ... > > > > > First point: a standard API for communication with Sage. > > > > Summary: Ted proposed a standard API to talk with a Sage session, > taking > > the Mathematica API as an example. He has done a lot of work > > researching alternatives and even constructing an optional spkg and > > example using JSON (see http://trac.sagemath.org/sage_trac/ticket/1510) > > Several other people in the project have expressed views that the > > Mathematica API as too heavyweight for Sage and there has appears to be > > some confusion about what introducing a standard API would mean for the > > project. > > > > My thoughts: I'd like to continue the discussion about an API. I've > > extended the notebook (slightly) and so I've had some exposure to the > > notebook "API" for communicating with Sage. In my experience, that > > communication falls into two parts: the communication between the > > notebook and Twisted and the communication between Twisted and the sage > > session. The communication between Twisted and the notebook consists > of > > passing text blocks (the sage commands in a cell) and other fixed-field > > information, like the time it took to run a cell, whether to create a > > new cell, etc. The API there is very rigid and very notebook-centric > > (it was evolved as the notebook evolved). The communication between > > Twisted and the sage session is entirely a pexpect stdin/stdout type of > > communication. Nothing fancy or anything. > > > ... > > > > > > Whew. That was a long response and it's taken enough of my time. Is > > there anyone (left :) who wants to work on a communication API or wants > > to work on documenting the notebook with me? If not, then I'll > probably > > just continue learning about the notebook and document it as I have > > time, as well as continue work on interactive widgets. > > Can you recommend an "API for dummies"-type reference? > I might be interested in working on this. Hi, I justed wanted to chime in about the above discussion of JSON, API's and the notebook in general. Over the last couple of years I've had a lot of experience writing web applications and I wanted to share what I have learned. I work at UCSD, and most of the work I do involves involves writing some kind of interactive front end (Read: Browser+Javascript/AJAX) to some kind of computing backend (Read: Code running on some server, returning some result) I also work a ton on Knoboo, which is like the Sage notebook, but more generalized. So let me describe some of the actual pieces of Knoboo that are relevant to this discussion; I do this because I have code that actually does what I'll describe: 1) JSON: We use JSON is Knoboo to pass all data to the web browser. We never pass any html, ever. The reason this pays off because it *decouples* the data (code+results) from the display (html+css+javascript). Specific example of this paying off: You want to add a new interactive feature to the notebook? All you do it add code to some javascript file, you don't ever touch the data coming from the server and all the files that deal with that interaction. It is this seperation of concerns that saves you in the long run. 2) API's: So, JSON really isn't above API's per se, it's about separating data from display. Having an 'API' is more about having some some 'interface' the you can 'call' to return some data, given some 0 or more arguments. This means (in English ;) if I want to evalutate the piece of code "factor(12345)", you don't want to think about how or where this might occur (to some extent), but only that if you sent the "computing engine" some code, in a precise why that is specific by the API, then it will return some data in an exact way specified by the API. This brings me to the notion of a "kernel", which is where the code runs. In the Sage notebook, the "kernel" is a separate Python (Sage) process that gets passed data through Pexpect. It doesn't have to be like this (using Pexpect). In Knoboo we *decouple* the idea of a kernel, it could be another Python (Sage) process, with communication through Pexpect ... but it also couple be another Python (Sage) process running a very minimal XML-RPC server, and all communication occurs through *** HTTP instead of Pexpect ***. This is what we are doing in Knoboo, it works, and it has these benefits: 1) No Pexpect (XML-RPC work on Windows because HTTP does!) 2) Standard API (Google for XML-RPC in any language (Python, Java, Ruby, Perl, etc), they all have clients and servers!) 3) Remote Kernels (Have a secure, dedicated machine where all computation occurs!) I would love to continue discussing this with anyone interested. -Alex > > > > > > Over on sage-edu, we ought to pretty quickly get a focus so that we > > don't become too fragmented to do any good. > > Maybe this should be another thread but possible topics: > (1) writing education materials which are integrated with SAGE, such as > http://sage.math.washington.edu/home/wdj/teaching/granville-calculus/ > (2) API related stuff? > (3) package for Geogebra? others? > > > > > Jason > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
