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 -~----------~----~----~----~------~----~------~--~---
