<div dir="ltr">Ah, I see Transform.ts now.<div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 6:18 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">$ cat Transform.js<br>"use strict";<br>exports.__esModule = true;<br><div><br></div><div>Is this what you were referring to???</div><div><br></div><div>Thanks,</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 8:20 AM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
But that is distracting and confusing way to solve a problem and leads to "fire, ready, aim!" implementation pathologies.<br>
<br>
A further risk might be that JSweet might carry through unnecessary Java programming idioms, but presumably they have sorted through that well already.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Authoring use-case environments are<br>
1. Script inside X3D scene graph,<br>
2. Script in outer HTML5 web page,<br>
3. Standalone programmatic use in node.js<br>
<br>
Now get specific.  Recommend listing pseudocode and design patterns for JavaScript Transform class and JavaScript X3D types, comparing:<br>
<br>
a. X3D ECMAScript specification,<br>
b. X3D Script code fields (class variables) and methods,<br>
c. good general-practice OO design pattern(s) in common use,<br>
d. current X3D JSON approach, is it OK or improvable further?<br>
e. compare/contrast Transform approach with X3DJSONLD,<br>
f. compare/contrast Transform approach with X_ITE,<br>
g. compare/contrast Transform approach with X3DOM,<br>
h. compare/contrast Transform approach with three.js,<br>
j. compare/contrast Transform approach with any other javascript libraries of interest,<br>
i. compatibility of Transform approach with Angular, React, jquery, other common JavaScript frameworks for HTML.<br>
<br>
We did this kind of comparison for X3D JSON design and it helped make a confusing understandable, eventually leading to good design decisions.<br>
<br>
If interested parties prepare this kind of comparison, and understand "what" we want that has general appeal, then progress refinement will be straightforward.<br>
<br>
Many people use JavaScript these days, especially with node.js - check whether they like the result.<br>
<br>
When you have solid patterns then we convert 4,000 X3D example scenes (from .x3d -> .js) to match, providing unit tests.  Lather, rinse, repeat...<br>
<br>
Hope this outline helps.  Good luck out there!  8)<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
</blockquote></div>
</blockquote></div>