[x3d-public] Priorities
John Carlson
yottzumm at gmail.com
Thu Oct 15 16:30:12 PDT 2020
---------- Forwarded message ---------
From: John Carlson <yottzumm at gmail.com>
Date: Thu, Oct 15, 2020 at 6:21 PM
I’m merely suggesting that implementing a new language for scripting would
help fix the duplicate “script” tag conflict between X3DOM and X3D. One
could implement X3D ECMAscripting language—assuming one could use a type
attribute on the script tag (as allowed by HTML5 extensions I believe).
There’s a python web scripting language called brython if you want to check
it out. I think most people will use it standalone due to sand boxing
issues, but I’ve only used it once.
I’m sure there are many more issues to be worked out.
It seems like WASM and python are changing what the meaning of web app is.
That’s why I’m suggesting that’s people compile their X3D browsers to
WASM, just to see if it’s possible.
I understand there’s still a single parent issue.
Andreas has made some inroads into implementing Protos with X3DOM. I’m
currently working on scripts, with the hope of integrating Protos with
scripts. A lot of the lessons learn are carrying over from X3DJSONLD.
We obviously could have created the “X3DScript” tag a long time ago.
However, this will not be standardized, so I’m looking at alternatives
that are backwards compatible. A new scripting language using the
existing script tag looking mighty attractive. And likely requires no or
few changes to the standards.
So,
Since X3DScript is not an option and brython cannot be used for old
documents, it seems like a new scripting language based on fields and
ECMAscript is indicated. This may require an initialize or onload event
handler (see brython).
So whoever suggested using a JavaScript implementation gets 1 point. Now
I need a JavaScript implementation with fields that can be used in a web
browser.
John
On Thu, Oct 15, 2020 at 5:26 PM Leonard Daly <Leonard.Daly at realism.com>
wrote:
> John,
>
> I don't really understand the question. The HTML5 script tag does not
> specify a language, though JavaScript is assumed (
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script).
>
> Certainly a scripting language can be created (or used) in the HTML5
> script tag. Since it is an HTML document, it would be a web scripting
> language. I think you are implying more, but I'm not sure what.
>
> There are many web APIs. The most obvious one is DOM. DOM's API is
> expressed in JavaScript. If you were to have another language, it would
> either need to generate a JavaScript call to the DOM API or DOM would need
> to be expanded to support another language interface. Other web APIs have
> their own requirements - it would depend on the API.
>
> Leonard Daly
>
>
>
>
> Would you agree that a new web scripting language could be implemented
> with existing web API?
>
> Thanks!
>
> John
>
> On Thu, Oct 15, 2020 at 4:49 PM Leonard Daly <Leonard.Daly at realism.com>
> wrote:
>
>> John,
>>
>> X3D is incompatible with HTML5.
>>
>> Any attempt to force-fit X3D into HTML5 is jury-rigged, at best.
>>
>> X3D doesn't fit into HTML because of duplicate tags, separate
>> name-space/scopes, multiple-parenting of nodes (to mention a few big
>> items). Also, HTML philosophy has evolved since 1997 while VRML/X3D has
>> not. At one time things were not too badly misaligned. Since then HTML has
>> diverged (think DOM for one).
>>
>> According to Semantic Versioning (https://semver.org/), major releases
>> are for "MAJOR version when you make incompatible API changes...". X3D is
>> more than just an API, but I don't see an incompatible or breaking change
>> with the proposed release. So according to that view, this really should be
>> X3D V3.4 (I think). Calling it X3D V4 is purely a marketing feature.
>>
>> If people are serious about putting scripts and prototype capabilities
>> into X3D running in HTML; then the fundamental design and philosophy of X3D
>> needs to be re-thought so it is compatible with HTML and not require HTML
>> to fit the X3D model.
>>
>> Leonard Daly
>>
>>
>>
>>
>> I believe it was Leonard’s conclusion that the script tag could not be
>> overridden, but now it a appears that there’s a way to implement new
>> scripting languages (brython) inside the script node. Can we modify/add
>> X3D script fields and routes to X3DOM to provide events for a new scripting
>> language?
>>
>> Leonard, can you weigh in on adding a new scripting language to the
>> script node?
>>
>> Thanks!
>>
>> John
>>
>> On Thu, Oct 15, 2020 at 4:06 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> Yes, we are considering 2 different tags, script and X3DScript. What
>>> we’re trying to figure out is whether script tag can be overridden/extended
>>> to provide fields in X3DOM. I believe this can be done by providing a new
>>> script type (ala brython). We know X3DScript already has fields, but we
>>> need more research on events and routes.
>>>
>>> On Thu, Oct 15, 2020 at 3:51 PM Andreas Plesch <andreasplesch at gmail.com>
>>> wrote:
>>>
>>>> Hi John,
>>>>
>>>> yes, your memory is correct. x3dom does not know about a script or
>>>> x3dscript x3d node. You would have to implement it as a new node.
>>>>
>>>> -Andreas
>>>>
>>>> On Thu, Oct 15, 2020 at 4:09 PM John Carlson <yottzumm at gmail.com>
>>>> wrote:
>>>> >
>>>> > Yes, I’ve added the field types.
>>>> >
>>>> > Now the question for the master branch is, what JavaScript is
>>>> necessary to add fields to X3DScripts, and how do we mesh Protos with
>>>> X3DScripts.
>>>> >
>>>> > The question for the Script branch is whether it’s going to work with
>>>> existing X3DOM architecture, in particular, what were the issues behind
>>>> previous implementation efforts. I think the best way forward would be
>>>> implement a new scripting language for script nodes which includes fields.
>>>> We should be able to follow brython’s example.
>>>> >
>>>> > For me, the failures of previous attempts were found in the
>>>> debugger. If I recall correctly, the Script node or field node was not
>>>> considered first class X3DOM nodes so we couldn’t route to/from it. I
>>>> need to start the debugger again.
>>>> >
>>>> > On Thu, Oct 15, 2020 at 8:30 AM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >>
>>>> >> All field type constructors and methods are defined fields.js .
>>>> Since x3dom is operating together with other scripts on the page everything
>>>> needs to be namespaced. Instead of
>>>> >>
>>>> >> new MFInt32()
>>>> >>
>>>> >> there is a
>>>> >>
>>>> >> new x3dom.fields.MFInt32()
>>>> >>
>>>> >> I think John added appropriate helpers which should work in an
>>>> encapsulated function scope under which all X3Dscripts execute.
>>>> >>
>>>> >>
>>>> >>
>>>> >> ---on the phone---
>>>> >>
>>>> >> On Thu, Oct 15, 2020, 2:45 AM Don Brutzman <brutzman at nps.edu> wrote:
>>>> >>>
>>>> >>> Color me very surprised if X3DOM doesn't have field types already.
>>>> >>>
>>>> >>> On 10/14/2020 8:52 PM, John Carlson wrote:
>>>> >>> >
>>>> >>> > I've added the following test to x3dom (coderextreme's master
>>>> branch). There are some pretty basic things such that it doesn't work,
>>>> below--MFInt32 not defined. Do I need to define all field Types? Can do,
>>>> I've done it before! I probably need to do it in the same scope as
>>>> initialize?
>>>> >>> >
>>>> >>> > I will pursue adding field types for now. Wish me luck!
>>>> >>> >
>>>> >>> > Thanks.
>>>> >>> >
>>>> >>> > x3dom-full.debug.js:45007 Adding fields
>>>> >>> > x3dom.registerNodeType.defineClass.nodeChanged @
>>>> x3dom-full.debug.js:45007
>>>> >>> > x3dom-full.debug.js:45034 Number of fields 6
>>>> >>> > VM46:31 Uncaught ReferenceError: MFInt32 is not defined
>>>> >>> > at eventsProcessed (eval at nodeChanged
>>>> (x3dom-full.debug.js:45126), <anonymous>:31:16)
>>>> >>> > at initialize (eval at nodeChanged
>>>> (x3dom-full.debug.js:45126), <anonymous>:24:2)
>>>> >>> > at eval (eval at nodeChanged (x3dom-full.debug.js:45126),
>>>> <anonymous>:236:41)
>>>> >>> > at
>>>> x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged
>>>> (x3dom-full.debug.js:45139)
>>>> >>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11796)
>>>> >>> > at
>>>> x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged
>>>> (x3dom-full.debug.js:33648)
>>>> >>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11796)
>>>> >>> > at x3dom.NodeNameSpace.<anonymous>
>>>> (x3dom-full.debug.js:11789)
>>>> >>> > at NodeList.forEach (<anonymous>)
>>>> >>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11787)
>>>> >>> > x3dom-full.debug.js:45007 Adding fields
>>>> >>> > x3dom.registerNodeType.defineClass.nodeChanged @
>>>> x3dom-full.debug.js:45007
>>>> >>> > x3dom-full.debug.js:45034 Number of fields 5
>>>> >>> > x3dom-full.debug.js:45007 Adding fields
>>>> >>> > x3dom.registerNodeType.defineClass.nodeChanged @
>>>> x3dom-full.debug.js:45007
>>>> >>> > x3dom-full.debug.js:45034 Number of fields 5
>>>> >>> > x3dom-full.debug.js:45007 Adding fields
>>>> >>> > x3dom.registerNodeType.defineClass.nodeChanged @
>>>> x3dom-full.debug.js:45007
>>>> >>> >
>>>> >>> > create mode 100644 test/functional/Gears/Rotor.x3d
>>>> >>> > create mode 100644 test/functional/Gears/gears.x3d
>>>> >>> > create mode 100644 test/functional/Gears/index.html
>>>> >>> >
>>>> >>> > http://localhost:8000/test/functional/Gears/
>>>> >>> >
>>>> >>> > Thanks,
>>>> >>> >
>>>> >>> > John
>>>> >>> >
>>>> >>> > ---------- Forwarded message ---------
>>>> >>> > From: *John Carlson* <yottzumm at gmail.com <mailto:
>>>> yottzumm at gmail.com>>
>>>> >>> > Date: Wed, Oct 14, 2020 at 9:54 PM
>>>> >>> > Subject: Re: [x3d-public] Priorities
>>>> >>> > To: Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>>
>>>> >>> > Cc: X3D Graphics public mailing list <x3d-public at web3d.org
>>>> <mailto:x3d-public at web3d.org>>
>>>> >>> >
>>>> >>> >
>>>> >>> > I will be pursuing getting X3DScript working entirely within
>>>> x3dom this evening.
>>>> >>> >
>>>> >>> > John
>>>> >>> >
>>>> >>> > On Wed, Oct 14, 2020 at 9:44 PM John Carlson <yottzumm at gmail.com
>>>> <mailto:yottzumm at gmail.com>> wrote:
>>>> >>> >
>>>> >>> > X3DJSONLD only has limited functionality for X3DScript. I
>>>> stripped it because X_ITE did not have support, so none of my X3DScripts
>>>> were working. I hope we can get X3DScript added to XMLSchema, X3DUOM etc
>>>> >>> >
>>>> >>> > Thanks, Don
>>>> >>> >
>>>> >>> > John
>>>> >>> >
>>>> >>> > On Wed, Oct 14, 2020 at 9:33 PM John Carlson <
>>>> yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>>> >>> >
>>>> >>> > If I recall correctly, full support for SAI will require
>>>> a Browser implementation. I suggest someone scope out the work for that,
>>>> if any. That is, much of the functionality may be there. It’s important
>>>> to distinguish X_ITE’s Browser from X3DOM’s in any case.
>>>> >>> >
>>>> >>> > John
>>>> >>> >
>>>> >>> > On Wed, Oct 14, 2020 at 9:22 PM John Carlson <
>>>> yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>>> >>> >
>>>> >>> > Andreas, can you share any info about why field
>>>> routing may not be working for X3DScripts in X3DOM? See coderextreme
>>>> repository.
>>>> >>> >
>>>> >>> > When I get a chance, I will peek at proto
>>>> declare/interface fields, but my understanding is those go away!
>>>> >>> >
>>>> >>> > Note that I’m not currently working on SAI for X3DOM,
>>>> but I do have some preliminary steps for declaring field types.
>>>> >>> >
>>>> >>> > John
>>>> >>> >
>>>> >>> > On Wed, Oct 14, 2020 at 6:45 PM Don Brutzman <
>>>> brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>>> >>> >
>>>> >>> > On 10/13/2020 8:26 PM, John Carlson wrote:
>>>> >>> > >
>>>> >>> > > Here’s may be possible: X3DScript node for
>>>> X3DOM and X_ITE. PROTOs with scripts
>>>> >>> >
>>>> >>> > Script node support is is always topmost
>>>> deficient. X3DOM without scripts is not compliant X3D or VRML.
>>>> >>> >
>>>> >>> > Prototypes are tied for importance, as in Really
>>>> Really Important for X extensibility.
>>>> >>> >
>>>> >>> > Please continue sharing information with Andreas
>>>> so that this might all land and work. Thanks John.
>>>> >>> >
>>>> >>> > all the best, Don
>>>> >>> > --
>>>> >>> > Don Brutzman Naval Postgraduate School, Code
>>>> USW/Br brutzman at nps.edu <mailto: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
>>>> >>> >
>>>> >>>
>>>> >>> 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
>>>>
>>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> LA ACM SIGGRAPH Past Chair
>> President, Daly Realism - *Creating the Future*
>>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Past Chair
> President, Daly Realism - *Creating the Future*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201015/86cebae0/attachment-0001.html>
More information about the x3d-public
mailing list