<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>The important thing about bringing VRMLScripting into X3DOM is that the Script tag (whatever we call it) itself doesn’t matter. What matters is the <field>s for ROUTEs, and how we send values from fields to VRMLScript and back.   So let’s focus on <field>s instead of <Script>, <script>, etc.  We need the Script fields to react to the rest of the event framework in X3DOM, so we don’t have to set up a whole new eventing framework for VRMLScript in X3DOM.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Let’s assume that the Script tag naming solution is solved, and proceed with supporting the stuff around it.</p><p class=MsoNormal><br>I do think that Scripts may need to be duplicated in the Proto Expander if the Scripts appear in a Proto (how do we want to handle Protos in X3DOM?), but would like more feedback on this subject (why must Scripts be done before Protos?) from Leonard.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here’s a concrete example if we want to discuss it:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a href="https://coderextreme.net/X3DJSONLD/src/main/html/index.html">https://coderextreme.net/X3DJSONLD/src/main/html/index.html</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>select ./data/bubs.json in the upper left pulldown.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here’s the data before processing by the client:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/bubs.json">https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/bubs.json</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I am *<b>not</b>* saying my solution is a good one (yet). I need to avoid evals, and have been thinking about that.  However,</p><p class=MsoNormal>If we take my event loop out of the question, and just use X3DOM’s event loop, I think my 3 eval problem can be converted to a single new Function() (scoping issue solved). Another thing that might solve my problem is nesting new Function() – what do you think? Hmm.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Note that both x_ite and x3dom use eval in the versions I am looking at.  We’re not doing too well at listening to Leonard.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We also need to think about applications which support multiple canvases with same or similar X3D file showing, and how to manage ROUTEs and Scripts with that.  I have been putting some thinking behind that. See:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>see “class Scripts”, loadScripts takes X3D data, a selector to make it unique on the page, and a url to distinguish files (say an XML and JSON file with same selector and different URL).</p><p class=MsoNormal><br>I would love for some one to take over some responsibility for Script.js in the X3DOM community. It’s a WIP.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Also, for Scripting we need to make sure that id’s are unique on the page. If we load the same file In X3DOM and X_ITE, how do we support JavaScript referencing an id through the DOM API?  How do we handle DEF when we load the same file in 2 different browsers on a web page?   What if there’s JavaScript DOM on the page which references the DEF?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is why we need careful thinking (thanks Leonard), especially when it comes to loading the same file more than once on a page.</p><p class=MsoNormal><br>I think we can use X3DJSONLD to experiment with some of these issues, and Leonard has ferreted out some of the problems, but there’s probably more.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I would like to emphasize again is that the Script fields are what we need to focus on what we need to get into x3dom.  I think it might get rid of my reason for messing with scripts altogether, or for the most part.  I think we might need ROUTEs to work with JavaScripts, if there’s a plan to do that.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If there are good reasons NOT to support VRMLscripting, these need to be supported with reasons, not just affirmations.   We need to be notified of security and technical reasons for sure.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p></div></body></html>