On Wednesday, December 28, 2016 at 3:47:53 PM UTC-8, Andrey Novoseltsev wrote: > > On Tuesday, 27 December 2016 15:34:51 UTC-7, Paul Masson wrote: >> >> I'm very much in favor of making Three.js a standard package, with the >> following caveats: >> >> 1) As of r80 the Three.js library has been reorganized to use ES6 >> Modules. There is little point in asking people to download the entire >> library (even with examples excluded as in the current optional package) >> unless we're going to make Node.js a standard package as well. >> >> 2) The template only needs two files to function: the main build file, >> minified or not, and OrbitControls.js for allowing user interaction. As a >> standard package I'm in favor of Three.js only including the parts of the >> library that will actually be used. If another file is needed in the >> future, it can be added then. >> > > If nobody objects and you can make a package taking care of these points I > should be able to review it! >
Should I rewrite the current optional package to download only the minimum needed files, or leave it alone and create a new threejs_min package? > > >> >> 3) As part of the review process of #12402, Andrey asked >> <https://trac.sagemath.org/ticket/12402#comment:37> me explicitly about >> the ease of embedding Three.js output in web pages. While I certainly want >> to add a local copy of the required Three.js files for offline use, I'd >> like to keep the output as portable as possible, and the simplest way to >> achieve that is with a CDN link in the file. The template can be modified >> to check for a local copy and fall back to the CDN or vice versa, but the >> HTTPS issue would still need to be fixed on the server. >> Alternately, a flag can be added to the viewer to specify that >> generated output will be for online use and the template modified at >> runtime to use the CDN rather than the local copy. That would of course >> require an extra input from the end user, but may be preferable to the >> majority. >> > > Well, if someone is going to embed plots into their webpage, presumably > that someone is capable of following simple instructions like "add this > script tag to the head". Note also that most of the time people will not > save the output, so while it is important to support saving/embedding, > proper showing is the first priority and at the moment SageNB does not work > over HTTPS. Presumably there would be no problems if scripts were served > from local installation. > I'm not understanding what the problem is with SageNB: the Three.js viewer already works just fine in the legacy notebook. What issue is there with downloading an external script securely? > > On Monday, December 26, 2016 at 7:16:55 PM UTC-8, Andrey Novoseltsev wrote: >> >> Hello, >> >> How about making threejs a standard package? >> >> It was optional for a while, used in SageMathCell to power its own >> version of threejs viewer. https://trac.sagemath.org/ticket/12402 has >> added threejs as possible output for a bunch of backends and ideally it >> will become standard for all interfaces. One of the problems now - the >> template loads scripts from the Internet, which means no offline use and >> causes issues with HTTPS anyway. >> >> Thank you, >> Andrey >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
