[x3d-public] [x3d] X3D-HTML event passing, let's look at simplest aspects first

[John Carlson]

Don, I am not interested in chasing loops around.   I put a full effort
into creating a scenegraph to JavaScript connection for X3DOM.   It’s time
to go somewhere else to look at the alternatives.   I highly suggest
looking at X_ITE’s code and other working code.  My code seems to be
fundamentally incomplete (does not handle namespaces properly for one).

It starts to get really complex when you use a node as a field.  A field is
not just a signpost

If someone wants to tell me X3D scripting is done for X3DOM, I will go look
at it.   I see absolutely no evidence that fields are handled for Scripts.

I am not focused on X3Dv4 and have other tasks.

I do not want to battle over email.   I am just trying the best I can to
report the effort I made.

John

On Sun, Mar 3, 2019 at 4:33 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Thanks for your helpful analysis John.  Here are some reactions.
>
> Expectation: field definitions for Script and ProtoInstance merely define
> logical connections where events are sent + received.  Of course a
> particular DOM node labeled "field" with name/type/accessType/value
> attributes is not the final destination we are interested in connecting -
> that particular DOM node is simply a signpost label, pointing towards
> author code living elsewhere inside the actual X3D player.
>
> Basics: the X3D scene is integral within the X3D browser, and the HTML
> scripts are external in the HTML page within the HTML browser.  Each is a
> separate set of content, handled by a pair of browsers running in separate
> blocks of code.
>
> We are figuring out the best way for an author to define connections for
> those events that are expected to pass back and forth between HTML page and
> X3D scene.
>
> The DOM representation of X3D scene content is just that - a
> representation - and any X3D player needs to listen and relay events in
> either direction.
>
> Remember that an "event" is simply a timestamp + value, getting passed
> from source to destination.
>
> There may be several ways for browsers to implement such event passing
> between HTML and X3D content using JavaScript.  Varieties of implementation
> are fine since the X3D Specifications do not legislate how the code must be
> written - rather the X3Dv4 specification will simply define syntax and
> semantics for such event passing.
>
> Thinking even more simply: of course the same activity must happen for all
> the other X3D nodes that produce or consume events.  The functionality for
> other nodes is already defined in the specification already, so that is
> considered straightforward in comparison.
>
> Why not start easy and gradually step up the sophistication, rather than
> first "diving into the deep end of the pool" with Script and ProtoInstance.
>
> Suggest we focus first on easiest aspects:
> a. defining HTML/X3D syntax for how simple string events can get passed
> between X3D scene and HTML page.
> b. defining HTML/X3D syntax for how numeric/typed events can similarly get
> passed.
> c. Look at X3DOM and X_ITE respectively and see how they do it currently.
> d. Get through basic event-passing first before tackling variations for
> author-defined Script and Proto fields (the extensible X in X3D).
>
> Wondering what our simplest possible [HTML page + X3D scene] example might
> be to show simple string event passing?
>
> v/r Don
>
>
> On 3/2/2019 1:57 PM, John Carlson wrote:
> > Yeah, I was relaxing most of the day yesterday.  I may have posted
> incorrect information.    But I still believe x3dom fields are not handled
> at all for scripts, based on prior research, and up-to-date investigation
> in the chrome browser (fields and related attributes are black for
> scripts).   .  They are handled for ComposedShader, and we might use that
> as an example for handling Script fields.
> >
> > Good luck, it’s up to someone else besides me.  It should be fairly
> simple to activate script fields I hope.  I am not sure you want them in
> HTML scripts anyway.
> >
> > John
> >
> > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> >
> > *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> > *Sent: *Friday, March 1, 2019 6:11 PM
> > *To: *John Carlson <mailto:yottzumm at gmail.com>
> > *Cc: *X3D Graphics Working Group <mailto:x3d at web3d.org>; X3D Graphics
> public mailing list <mailto:x3d-public at web3d.org>
> > *Subject: *Re: [x3d] X3D meeting minutes 22 FEB 2019: X3D v4 Development
> statuscategories
> >
> > Thanks for these observations John.
> >
> > I think this points us at the importance of syntax for sending events to
> destinations, either (X3D -> HTML) or (HTML -> X3D).
> >
> > There are several links in today's minutes of relevance: event
> descriptions and diagrams for both X3D and HTML.
> >
> > The X3Dv4 spec defines functionality - this will tell authors how to
> construct what they need, and tell implementers what syntax/semantics to
> support.  In other words, interoperable content.  It does not mandate how
> an implementation gets coded.
> >
> > Building examples and comparing X3DOM and X_ITE together should get us
> on path to convergence.
> >
> > It would be good to get Roy Walmsley's original HTML+SVG+X3D+Javascript
> demo of "bouncing ball" back on center stage and refreshed.  Anyone know
> where it is?  Valuable role here for someone...
> >
> > On 3/1/2019 2:19 PM, John Carlson wrote:
> >
> >  > In other words, to prevent script source code from appearing on the
> rendered page, I had to remove the text or CDATA node. I am fairly sure I
> removed the field nodes as well for X3DOM in X3DJSONLD, favoring my own
> implementation.
> >
> >  > I believe that text nodes are incompatible with execution, but it
> might be worth seeing how something like jsfiddle does it, if they keep a
> shadow script or what.
> >
> >  > I believe you can keep the fields in DOM (I didn’t) if you have an
> X3DOM implementation of them.
> >
> >  > On Fri, Mar 1, 2019 at 4:03 PM John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>> wrote:
> >  >     In other words, scripts (really script fields) do not appear in
> DOM and do not receive or generate DOM events.
> >
> >  >     John
> >
> >  >     On Fri, Mar 1, 2019 at 3:46 PM John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>> wrote:
> >
> >  >         As far as I know there is no Script “class” or source file in
> X3DOM, thus no place to hang fields, thus nowhere to hook up routes.  I did
> write one at one time, it didn’t seem that difficult, but I’m not presently
> on board to rewrite it.   I suggest looking at other implementations of
> fields.
> >
> > [...]
> 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/20190304/06db70d9/attachment.html>