I can't write much from my phone. But I think rejecting some use of java in the notebook out of hand is a very bad idea, especially given the recent open sourcing of java. Also java is our best hope for some notebook related problems, eg 3 d graphics.
- William (Sent from my iPhone.) On Aug 6, 2007, at 2:44 PM, [EMAIL PROTECTED] wrote: > >>> 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. > > Then read the notebook source. If you capture a key in a cell, it > might affect the rest of the notebook. Interrupting, opening > print / help windows, etc. Evaluating the bottom-most cell spawns > another cell. The list goes on. > > > >>> 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. > > > I remain skeptical. > > >> >> 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. > > Absolutely not. We tried a "change the cell when you click on it" > scheme for about two weeks. My ears are still ringing from all the > complaints I heard about it. > > > > > --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
