Hi All This was originally a discussion of how to make Sage a better desktop app.
Well, my two big annoyances about how Sages works today, as a pure web page are: 1: Inconvenient: its really annoying to have to start the sage process, then have another browser windows pointed at it. 2: This is the big one: No Publication Quality Output - by this I mean that the sage web server process uses matplotlib to produce raster images which are then displayed in the html, and for publication, I need vector plots i.e. pdf. I suppose it would be a big duplication of effort to write a python UI, as none of the code could be shared with the pure web page version, plus it would be a lot of work (probably wasted) to create a python binding to webkit. So, I agree, its best to keep the UI as Javascript. I think I have a way to dramatically improve the current web UI, that will result in publication quality output, and most likely simplify things a lot. Create a Sage Web Service, and have all data passed back and forth be in the form of 'expressions' which would be encoded as xml. This is really really similar to how the Mathamatica notebook communicates with the Mathematica kernel, though the 'MathLink' API. Now, HTML 5 combined with the new 3D canvas that is in the nightly builds of WebKit (I think Firefox supports this 3D canvas also) can render perfectly everything that Sage needs to render. By expression, I mean that the client would call, something like "plot(....)", this would return probably an set of SVG data, and the client javascript would just add this draw this inline via DHTML. Similarly for 3D plot data, the server would return a set of 3D polygon vertices, and the client javascript would just add these to a 3D canvas tag. The really nice thing about drawing in the client via SVG is that the client can export / save it as PDF! This web service approach I think would be a LOT simpler then the previous approaches, and would be probably 99.9% identical code between the desktop and the web server versions. So, what needs to be done for something like this: 1: come up with the web service API, I say just model it after Mathematica's MathLink. Expressions would just be encoded in XML. 2: set up mplotlib to produce SVG instead of raster images. 3: do the same for the 3D code, to just return an xml encoded polygon data. 4: code the web service. 5: code the HTML / Javascript front end to call the web service. Improving the desktop app version then becomes almost trivial - create a set of simple apps that just host a WebKit widget, package up sage into a directory, along with the html / javascript files for the UI, the app would then just fork a process to start the sage webservice, and viola, or even connect to a remote sage web service. On Jan 15, 2010, at 12:48 PM, William Stein wrote: > On Fri, Jan 15, 2010 at 9:42 AM, Robert Bradshaw > <rober...@math.washington.edu> wrote: >> >> On Jan 15, 2010, at 7:25 AM, Andy Somogyi wrote: >> >>> I think javascript is actually a pretty nice language. It has some really >>> nice functional features, is resembles Scheme in certain ways. The only >>> problem I have with javascript is that it is not the same language as sage >>> (python). If sage were written in Javascript, then of course it would be >>> natural to write the UI in Javascript. >>> >>> BTW, A patch was just submitted to WebKit that enables MathML rendering! >>> This means that a front end could have all the mathematical typesetting and >>> layout that Mathematica has! >>> >>> But back to the question, is it better to write the UI in Javascript which >>> implies that there needs to be a Python <-> Javascript glue layer (not too >>> big of deal, just develop some glue that does dynamic binding, or use remote >>> invocation), OR write the UI directly in Python which implies a bit of >>> WebKit <-> Python glue? The WebKit <-> Python glue is again not too big of a >>> deal, it already exists in Appcelerator Desktop (Again, Apache license), I'm >>> not sure how efficient it is as I've never used it. Or, have native bindings >>> to WebKit (generated via the WebKit idl files). >>> >>> Personally, I like the single language approach (all Python), makes things >>> SO MUCH simpler. >>> >>> Any thoughts? >> >> >> The advantage of the Python <-> Javascript glue layer is that you can share >> more code with the existing notebook. Otherwise, whenever you're >> implementing something the notebook already has, that's duplication of >> effort (and future maintenance), and when you're implementing something the >> notebook doesn't have, it won't benefit remote use. In the long run, I think >> that makes using Javascript for the UI a better option. >> >> Also, you have the advantage that the Javascript code already exists, rather >> than starting from scratch. It seems like the biggest drawback is not the UI >> itself, but rather that it isn't a "normal" desktop app with its own window, >> menu, etc. >> >> - Robert >> > > This question reminds me of this quote from the movie "Hurt Locker", > in which an army colonel is asking a bomb squad soldier about the best > way to disarm bombs: > > Colonel Reed: What's the best way to go about disarming one of these things? > > Staff Sergeant William James: The way you don't die, sir. > > > http://uk.imdb.com/video/screenplay/vi3242263065/ (50- seconds in). > > William > William > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
