On Dec 4, 2007, at 10:05 AM, Ted Kosan wrote: > Robert wrote: > >> Actually, that is the point of gluegen-rt.jar--it lets one ship >> native code (so/dll/dylib) libraries within the jars themselves, and >> why there has to be singed code involved. Does the 4x4 applet still >> work for you if you uninstall java3d? >> >>> Given that people already have to install java and fonts, I >>> don't think that's too much of a penalty. >> >> Java is already installed on many machines, and it still works >> (though not as pretty) without the fonts. If the user is able to >> install java3d it would make things nicer, but often they can't (e.g. >> students using computer labs). > > Of course, the difficulty is that the versions of Java that people > have installed varies and this causes support headaches :-) I am > still thinking that a less error-prone way to give people SAGE/Java3D > capabilities it to take your 3D applet, turn it into an application, > and then bundle it with its own customized copy of Java SE which has > been preloaded with the Java3D libraries. This will work for Windows, > Linux, and Solaris. For the Mac, an installer can be made, or just > user-friendly instructions created, on how to install Java3D. > Companies have been using the bundled JVM solution to solve problems > like this for years with excellent results.
I don't know that it would be any harder for the Mac--usually there's less of a need for an actual installer. However, in practice Java is fairly compatible platform-to-platform, and most computers already have it. It's the browsers that are an issue. A much lighter-weight solution would be jnlp which might have less issues too. > I am also thinking that a good way to use the Java3D application is in > cooperation with the notebook by having it log into the server > separately from the notebook. People can create 3D objects in the > notebook, view them interactively in the Java3D application, and then > send frozen images of the 3D scene back to the server for display in > the notebook. One disadvantage of not going through the notebook is that the notebook would then have to be continually polling the server to see if it needs to update its content based on the actions of other clients. I'm not saying this could not be done though. Also, how would one fire up the app from the notebook (especially if the server is remote)? > This approach will require a protocol to be created that graphic > clients can use to communicate with the sage server. I have been > studying the possibility of using a protocol based on JSON because > Java SE includes a Javascript engine, applets that are embedded into > the notebook (like JMathPlot) can interact with the firefox browser's > javascript environment using JSObject, and JSON is general enough to > be used by any language, which opens the door for a wide variety of > SAGE clients to be created. I am thinking that giving people the > capability to create their own custom SAGE clients will probably be > important going forward. > > As for student labs, people will just have to go through the same > software installation request procedure that all the other software > installed in the lab had to go through :-) I think that's one of the benefits of Sage--one can sit down at virtually any computer with a browser and start using it. That being said, I think looking at the possibility of multiple rich clients for interacting with Sage is a worthy cause to pursue, and. important to think about when designing the 3D capabilities. - Robert --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
