[x3d-public] JSweet translation of X3DJSAIL to JavaScript: need specific design goals first

John Carlson yottzumm at gmail.com
Tue Mar 24 16:18:32 PDT 2020


$ cat Transform.js
"use strict";
exports.__esModule = true;

Is this what you were referring to???

Thanks,

John

On Tue, Mar 24, 2020 at 8:20 AM Don Brutzman <brutzman at nps.edu> wrote:

> John, certainly we need to pay attention to "how" a library conversion is
> performed.  JSweet is promising, and we have a number of conversion
> approached demonstrated already.
>
> But that is distracting and confusing way to solve a problem and leads to
> "fire, ready, aim!" implementation pathologies.
>
> A further risk might be that JSweet might carry through unnecessary Java
> programming idioms, but presumably they have sorted through that well
> already.
>
> First things first, please.  Let's begin with defining design goals.
> That's how we accomplished creating Java and Python programming-language
> bindings for X3D.
>
> What we really need to understand is "what" a sharable X3D JavaScript
> library looks like, and how JavaScript programmers might then use it to
> author interactive X3D models.
>
> Authoring use-case environments are
> 1. Script inside X3D scene graph,
> 2. Script in outer HTML5 web page,
> 3. Standalone programmatic use in node.js
>
> Now get specific.  Recommend listing pseudocode and design patterns for
> JavaScript Transform class and JavaScript X3D types, comparing:
>
> a. X3D ECMAScript specification,
> b. X3D Script code fields (class variables) and methods,
> c. good general-practice OO design pattern(s) in common use,
> d. current X3D JSON approach, is it OK or improvable further?
> e. compare/contrast Transform approach with X3DJSONLD,
> f. compare/contrast Transform approach with X_ITE,
> g. compare/contrast Transform approach with X3DOM,
> h. compare/contrast Transform approach with three.js,
> j. compare/contrast Transform approach with any other javascript libraries
> of interest,
> i. compatibility of Transform approach with Angular, React, jquery, other
> common JavaScript frameworks for HTML.
>
> We did this kind of comparison for X3D JSON design and it helped make a
> confusing understandable, eventually leading to good design decisions.
>
> If interested parties prepare this kind of comparison, and understand
> "what" we want that has general appeal, then progress refinement will be
> straightforward.
>
> Many people use JavaScript these days, especially with node.js - check
> whether they like the result.
>
> When you have solid patterns then we convert 4,000 X3D example scenes
> (from .x3d -> .js) to match, providing unit tests.  Lather, rinse, repeat...
>
> Hope this outline helps.  Good luck out there!  8)
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200324/960fca5e/attachment.html>


More information about the x3d-public mailing list