boothby wrote: > *each* cell is an instance of an applet? That is an utter nightmare for a > number of reasons: > > 1) browser-applet interaction is > * highly restricted > * buggy > * different in every browser
Browser/applet interaction is restricted, but the interaction between the applet and the servers it was served from is unrestricted. Since the data that a user is working on is on the server, I do not see why very much browser/applet interaction would be needed. > 2) For an entire quarter, I tried, every week, to install java into my > browser so that I might preview the assignment in a browser before I turned > it in. Every week, I gave up, booted up my windows box, and tested it there. > I read a lot of tutorials, and none did a bit of good. To this day, java > applets don't work in my browsers. Other people may have better luck. But > java applets under linux are far from ready for prime time. First I must state that installing Java on windows is extremely easy and not an issue. It use to be much more difficult to install Java on Linux because Java was proprietary and therefore the Linux distributions would not support it. Since Java was open sourced, however, the Linux distributions have been making the Java installation process increasingly easier. See: https://jdk-distros.dev.java.net/ > 3) I frequently use worksheets with hundreds of cells. This, in turn, runs > my computer out of memory. This is not using java. Add the overhead of an > applet for every cell... you get the idea. Sun's Java-SE implementation has included Class Data Sharing since version 1.5: http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html So, I do not think that one can assume that having multiple applets running will use too many resources without testing this. If the resource usage was too high, then an alternate strategy of just using one applet and then binding it to the current cell being edited could be explored. Ted --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
