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

[Andreas Plesch]

Hi John, Don,

I am trying to follow the discussion somewhat but have quite limited
availability now.

Here are some considerations, unfortunately quite unconnected.

Ecmascript best practices

It is not clear that there are commonly accepted standards since the
language is forgiving having evolved so much. But here are perhaps
some guides. An often encountered viewpoint is that the language is
not very OO oriented but rather functional in nature. So OO principles
do not necessarily apply but could be used anyways. There are now
classes in Ecmascript although my understanding is that they are
largely considered syntactical sugar. Another principle is that since
it is a largely interpreted language which relies on garbage
collection, object reuse is favored over object creation and
destruction. Three.js, for example, is very strict about this, and
part of the reason why it is performing well. x3dom is not very strict
about this on the other hand, and still does ok. As node.js is a
target one needs to be careful to distinguish between DOM/browser
features and language features. Node.js natively does not have DOM
methods but a DOM and methods can be added with a library. Also, keep
in mind that currently there is no X3D runtime for node.js.
x3dom/x_ite cannot be run in node.js. So one, expensive, experiment
would be to try to extract a node compatible runtime by separating the
rendering and input controls out of these engines.

Scene Authoring/Construction versus Scene Access

Ecmascript differs from Python or Java in that it is the primary
language for X3D scripts used internally in scenes, and externally to
access scenes in running browsers. This is what the current SAI spec.
defines, and what I understand to be Scene Access. This includes but
is not limited to constructing new nodes and entire scenes
programmatically. In addition to construction, SAI also allows for
controling a browser, and modifying a running scene. In contrast,
X3DJ/PSAIL is limited to constructing and authoring a scene which can
eventually be serialized as xml or json, and be used to load into X3D
browser. It seems perhaps prudent for now to parallel X3DJSAIL and
just focus on scene authoring, and not be concerned about live scene
control and modification.

JSON

Since the X3D JSON encoding now exists, a useful and specific question
is if the Ecmascript JSON.parse() function
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse)
should return a value which can be immediately used by the envisioned
library given a JSON encoded string. Conversely, should the Ecmascript
JSON.stringify() function generate directly X3D JSON encoding if given
a library generated object ?

-Andreas



On Tue, Mar 24, 2020 at 9: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



--
Andreas Plesch
Waltham, MA 02453