Thanks, Jason, for the lengthy reply. I think it summarizes things nicely.
I started a simple API at the AMS meeting in January, and I think the time is ripe to have a discussion about this. I'll start a new thread summarizing my ideas (probably on sage-edu) when I have a bit more time (probably later today). - Robert On Feb 22, 2008, at 10:09 AM, Jason Grout 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). > > The bottom line (for me) is at the end of the message :). > > Also, you'll notice I'm starting a new thread. We probably should > have > done that when the discussion moved to bigger things than Geogebra. > I'll try to summarize main points here; apologies if I misrepresent > someone's comments or contributions. For reference, the original > thread > is at > http://groups.google.com/group/sage-devel/browse_thread/thread/ > 7a1420263df5d5e3 > > 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. > > I now focus on the JSON patch above, since that is the relevant code > that is currently on the table. Ted proposed using JSON and gave an > example in the ticket mentioned above a while ago. Personally, I'm > excited about a flexible way to communicate with Sage, especially > if it > is standard and lightweight. Robert Bradshaw posed a technical > question > about handling Cython classes and (to me and apparently Robert) the > question didn't seem to be answered fully. How would you pass a > Cython > object back to the client (I think that's the question, but I don't > know > very much about pickling, etc.)? I have been waiting for the > discussion > to reach the point that I could contribute something useful, but > apparently it already has: what is needed is cheering, so "Yeah! We're > on the right track; let's keep going!" :). For the record, my lack of > participation has nothing to do with a bias against Java; I'm sorry > Ted > got the impression that because some core developers hate Java that > all > of us do. My guess is that most of us haven't chimed in because we > don't have an opinion or don't really care what language is used for > client-side projects. > > On the technical side, I contributed a patch or two that modified the > display hook in python to display typeset expressions in the notebook, > which wasn't a big contribution, but it did help me understand that it > is very easy in python to commandeer the communication back to the > user. > I think developing something so that Sage returned a JSON expression > instead of, for example, typeset output, would be fairly easy, but the > contents of the JSON expression may not be very useful. It would be > trivial to return, for example, a JSON expression representing the > string that would normally have been returned. It would be harder, > but > doable after a lot of work, to do something like the current > pretty_print_default code does that queries each object for a > "show(type=JSON)" method and call that. Now I'll be looking at Ted's > patch to see how he did things. > > Second point: How sage-edu fits into the larger sage community > > Summary: The project leaders see sage-edu as a development area for > creating and refining spkgs to submit to the core sage community, as > well as creating the necessary patches needed to enable Sage to be a > more valuable tool in education circles. > > My thoughts: I agree with William and Michael that we ought to keep > the > community coherent and focused on Sage; we're too small to fracture > and > survive. However, I don't see any obstruction to people releasing > spkgs > of their own which have their own applets, source code included or > not, > which provide functionality on the client side. > > > Third point: Contributions versus discussion > > Summary: um, this seems to be the point of inflammation. I won't > summarize this, but I'll add my thoughts. > > My thoughts: I agree that patches are what count in the end, but we're > at the beginning here. William's idea seems to be that the people > that > need to carry out the discussion in the beginning need to be > grouped and > organized to do the work effectively. The evolution process need not > concern everyone. I agree. > > And now a more personal note to Ted; sorry for including replying to > this part of the discussion, but it probably ought to be publicly > stated. > > Ted, I really appreciate the contributions you've made. Just > yesterday > I pointed several graduate students and my postdoc mentor to your > newbies book. Apparently it's also been a "best-seller" to people > trying to learn Sage. I also appreciate your work on JSON and want to > continue that discussion and development; I was waiting for the > technical objections to be resolved since people were talking about > things that I had no experience in. I don't have any experience > developing applets, but I appreciate what you've done in that > area. At > one point I proposed some changes to the notebook organization to make > it easier to have applets have embedded cells in the notebook, but I > haven't contributed patches, so I'm not surprised that the interest > wasn't noted :). > > As for the java front end, on the one hand I haven't been that > interested since the notebook fills my needs and I don't have (a > lot of) > experience developing in java. However, one reason I think it's a > good > thing to have multiple front ends to Sage is the same reason that > mabshoff thinks we ought to support multiple platforms: better code > quality (and in this case, communication code especially) and better > versatility. I think there are definitely things that you could do > in a > dedicated front end that would not be very feasible in a web-based > front > end. I started researching using the Enthought platform for a front > end, so I'm excited to see the results of SD8 (and wish I could have > taken off the time to be there!). Personally I would be more > comfortable contributing to an Enthought or py-QT front end because > I'm > not experienced in Java, but I think you ought to go for it if you > think > it is the way to go. > > Personally, I'm realizing that there are far too many things I'd > like to > contribute patches for than I have time for. I'm trying to figure out > what would help Sage get ahead the best now. I agree that having some > nice way to communicate with a Sage session would open up lots of > possibilities for others to do more work, so I'm willing to help > with that. > > > 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. > > Over on sage-edu, we ought to pretty quickly get a focus so that we > don't become too fragmented to do any good. > > 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 -~----------~----~----~----~------~----~------~--~---
