[x3d-public] Requirements for X3DV4, event handling among multiple browsers on same page

[Brutzman, Donald (Don) (CIV)]

On 3/4/2019 1:36 PM, John Carlson wrote:
> Is it a requirement for X3DV4 to view the same file many with many instances (in same address space) in several different types of browsers (X_ITE and X3DOM on same page) at the same time?

I currently doubt that this will rise to the level of a specification requirement.  To my knowledge, whether or not an HTML Browser handles multiple windows is an implementation feature, not an HTML5 Recommendation requirement.

But maybe... good discussion topic.

> What restrictions are there (for example, no use of id attribute, or required use of id attribute)? How might we prevent or enable this?

Am thinking that this is how we can easily distinguish HTML Scripting addresses (via DOM element id) and internal X3D ROUTE connections (via DEF/USE)..

> X3DJSONLD has an implementation of this, but I haven’t figured out how to handle a single DOM event loop and a single X3D event loop for the page (Don’s double loop design).

Modern HTML browsers are likely to let HTML page rendering and X3D scene rendering proceed in parallel.

=========================================================================
HTML5.2 - 2.6.2. Processing model lists parallel operations for fetching:
https://www.w3.org/TR/html52/infrastructure.html#fetching-resources-processing-model

=========================================================================
More broadly, in 2.1. Terminology
https://www.w3.org/TR/html52/infrastructure.html#infrastructure-terminology

"When an algorithm B says to return to another algorithm A, it implies that A called B. Upon returning to A, the implementation must continue from where it left off in calling B. Some algorithms run in parallel; this means that the algorithm’s subsequent steps are to be run, one after another, at the same time as other logic in the specification (e.g., at the same time as the event loop). This specification does not define the precise mechanism by which this is achieved, be it time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads, cores, CPUs, machines, etc. By contrast, an operation that is to run immediately must interrupt the currently running task, run itself, and then resume the previously running task."
=========================================================================

> I think this has already been discussed, and I forgot?
> 
> This is critical for X3DJSONLD. I am thinking when DOM events get put on the X3D event loop. Is there only one X3D event loop or many?
> 
> Might I suggest tagging events with the browser selector and URL?

Since the HTML5 DOM tree has the entire document, including multiple embedded objects, there is likely an addressing mechanism already in the HTML5 specification.  Since the author can define a new id attribute for each instance, this may be already defined for us.

It will be good to do more examples.

> This might impact consoles that have a X3D Browser per player.
> 
> I can see X3DJSONLD going away.  Bye, it was pretty much an experiment anyway.

Not so fast!  There are a lot of open issues that we likely still need X3DJSONLD for.

> This obviously also affects any scripting code as well.  Should we avoid embedded scripts, or look at X3DJSONLD’s solution a bit more?
HTML5/X3D authors will likely want to do everything, consistently.  So we need repeatable authoring approaches and software solutions for X3D scenes within an HTML5 DOM tree.

> Why does my mind work in steps and can’t jump to the solution or next issue right away?

My usual excuse is a temporary coffee deficiency...

> Bounce back to you.
> 
> Thanks,
> 
> John


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