On Wednesday, 28 December 2016 18:12:36 UTC-7, Paul Masson wrote: > > > > 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? >
I am not sure what are uses of the current package beyond SageMathCell. If someone is aware of other cases, would be nice to know, otherwise I think it is fine to trim it as much as necessary to keep your new code operational. (For the record, the current size is 14M, so it would be nice if the standard package was a little smaller, although the long term plan is probably to make jmol optional and that will cut 37M.) > >> >> >>> >>> 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? > It is not working: I have SageNB running over HTTPS and using threejs shows just blank area and messages in console about mixed content blocked. My understanding is that if you are loading a page over HTTPS it should not requests components over HTTP or browsers will complain or just show nothing. There is no problem in the opposite case, so perhaps you can just always use secure CDN. > >> >> 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.
