On Jan 22, 2008 5:05 AM, Ted Kosan <[EMAIL PROTECTED]> wrote: > > William wrote: > > > > If further testing is successful, I would like to have simpleJSON > > > included in SAGE. What procedure do I need to follow in order to make > > > an official software addition request? > > > > (1) Convince us it's a good idea. You basically just did that. > > > > (2) Create a trac ticket and then to attach some code that > > we can try it out. > > A simpleJSON spkg has now been created and more information about it > can be found in its trac ticket: > > http://www.sagetrac.org/sage_trac/ticket/1510 > > William has added the following comment to this ticket which requests > that the spkg be discussed on sage-devel before deciding on whether or > not to include it in Sage: > > >I think some sort of general voting and discussion should occur > before including > >any new packages standard in Sage, especially ones that don't cover > some very clear > >mathematical area that is completely unconvered by Sage (e.g., R and > >PolyBori? > >did address a clear mathematical area). In particular, it is > _critical_ that there be > >more than one person who really wants the package to go in before we > even consider > >putting it in. I suggest that: > > > > 1. simplejson be made an optional package, > > 2. there be a post to sage-devel to start some discussion about whether > > this actually > >belongs in Sage. That it is is easy to put in > >Sage (it's pure python) is a plus, but is > >definitely not enough of an argument (to put it mildly). > > > >Remember, every package that goes into Sage will cause Michael > Abshoff, and me, > >and others headaches at some point, and will add > >to the horrendous problem we > >already have with packages getting out of date with upstream. > > > >Also, perhaps there should be somebody -- probably Ted in this case > -- who very clear > >volunteers to keep the package up to date for the next year, and find > somebody to take > >over if they can't continue. > > > >The above was quick brainstorming. It is not meant to be some well > thought out procedure, > >which is something I don't think we have yet. -- William > > The purpose for adding simpleJSON to Sage is to give clients an > object-based, language-neutral method for communicating with the Sage > server. This package is not about adding mathematical capabilities to > Sage, but rather, it is for allowing clients to more easily access the > mathematical functionality it already has. I am specifically using > simpleJSON to allow applets, which are loaded from a separate server > into a worksheet, to pull data out of Sage. Allowing applets to be > loaded from a separate server removes the need for them to be included > with Sage itself which I think is a good route to follow. > > I have estimated that there are probably hundreds of math, science, > and engineering-oriented Java applets in existence that are capable of > adding value to Sage. My goal with these applets is to not only make > them available in the notebook, but to also attract a significant > number of their developers to the Sage project so that they can add > even more value to it. > > If there is no easy way for these applets to communicate with the Sage > server, however, there is not much point in embedding them in a > worksheet. > > As for the idea of making simpleJSON an optional package, my thought > is that there is little point in this. If a newbie Windows user wants > to use a calculator applet in a worksheet because this is the level of > technology they are comfortable with, they are probably not going to > be very successful installing an optional package.
I can see you don't like the idea of making JSON merely an optional package but one possibly way to hopefully help your proposal would be to first make an optional package and then see how that goes. I think for William and Michael, the effort required to change an optional package to a standard package isn't great. On the other hand, it does make it easier for people to test (and even for you to create bug fixes) for optional packages. You could also add some details about it to the wiki at http://wiki.sagemath.org/optional_packages_available_for_SAGE So, I agree with William. > > Anyway, I researched a number of alternatives before choosing a > JSON-based solution to this client communications problem. It is > relatively clean and it seems to work fairly well. If people have > alternative ways to solve this problem, however, I would like to hear > them :-) > > Ted > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
