[x3d-public] [x3d]V4.0 Opendiscussion/workshoponX3DHTMLintegration

[Joe D Williams]

> I think that “Downloading a big set of scripts” is the wave of the 
> future.

well, ok, i mean certainly a user should be able to decide to 
optionally install in the browser some compact highperf custom feature 
extension. That means <x3d> ... </x3d> needs fallback content if the 
extension ain't there or limited or needs an upgrade. Sure, the 
exension might be some evolved compiled stuff especially for use as a 
common addon to all html browsers. After all, webGL is close to that 
category. With the great common html browser support for javascript 
and webGL, x3d has a great opportunity to demonstrate how some free 
and clear understandable and well-organized set of declarative 
structures, syntax, and event processing of X3D can leverage the dom 
and the webgl to make fun <x3d> everywhere.

Right now I think we are showing only a slight actual improvement over 
authoring using .x3d in an object or iframe and then asking the user 
to download the player to see the content. OK, I am spoiled because I 
had learned some about a couple of then enterprising VRML/X3D browsers 
now gone and I now use and depend on one for many judgemental details, 
BSContact free. I really works for me and from any html browser will 
run in a window from a clicked .x3d link or object or iframe. Really, 
for any fan of X3D, this has taken over as the best realtime 
interactive 3D web browser and the one most likelly to fulfill the X3D 
spec for the most part. There used to be more, but they went away. We 
see them now influencing glTF. Sure there were problems with VRML and 
X3D toolmakers jumping over each other and getting removed from open 
action, and the fact that the external interface of the player to the 
html DOM was very unpredictable, esp since EAI was being replaced by 
SAI.

If you saw the AJAX3D stuff, and tried to use other than tony's X3D 
browser then whatever was in the <object > probably did not recognize 
the getbrowser keyword the dom script sent to the object, for heck's 
sake. Remember that when you asked the dom to get the embedded 
x3dbrowser context, then from there on you sent/received codes of the 
embedded object. A DOM script composed x3d sai event strings and sent 
them to the x3d browser and since all are strings all i/o is ok.

In that way the object context always maintained control of what and 
when it executed the change and what and when it sent events. Its 
scene graph was independent of the DOM tree.
>From the DOM point of view this object/iframe was an independent bound 
context. If the object or iframe is html, then the 'external' dom 
script sends i/o keywords and data in html dom. If the iframe is x3d 
then the i/o keywords and data are in x3d sai.

Now in those days, asking X3D browser makers if they could use the 
host html browser javascript engine or would rather include their own 
independent javascript engine in their browser download, the answer 
was always quite clearly laughable since the html javascript was so 
weak relative to their tuned up 'internal' engines. I think now big 
html browsers all use mostly thej same spec script engine and mostly 
same spec dom processing. So, the current setup gives everyone a clear 
shot at what needs to be composed into host browser javascript engine 
and webGL to complete the X3D deal. Basically the best cross-browser 
implementations of x3d realtime interactive content using comparable 
host w3c web browser javascript and webgl engines should be used as 
models for desired extensions to the 'standard'  javascript engines 
and to the webgl available in common 3d-centric interactive web 
platforms.

Anyway, on one example of x3d integration with html documents presents 
an implementation that says ok we can give you standard x3d 
automations covering practically the complete X3D spec plus some nice 
additions because we have a very sweet set of scripts and other code 
and css to deal with the <x3d>. Almost all the expected x3d event 
creation, routing, and animation automation is there so you really 
don't need 'internal' scripts (or protos). And yes, we use the browser 
script engine and we probably currently just don't want to share that 
with 'internal' x3d scripts running SAI features. If you want to 
script the <x3d> ... </x3d> then use an 'external' DOM script and 
unlike an embedded or standaone player, don't use x3d sai syntax, 
instead use html dom. And unlike a fully conforming X3D SAI, you don't 
need to worry about begin/endupdate, just send those dom events and 
x3d keywords and data in and out whenever you can and it will be taken 
care of. The x3d scenegraph is shadomified so if if it is changed by 
the dom script or the internal automation we will know.  If that 
doesn't work as expected then build some dom event 
emitdetectroutecomputeexecuteupdate system that does what you need.

Likewise, historically there are other variations on this but the 
important fact is that in order for x3d to be everywhere, the 
interactivity and animation tools must be built-in to the host in the 
same way as is the webgl graphics and basic javascript. The <html>... 
<x3d> ... </x3d> ... </html> handling of authored and user initiated 
interactions must leverage the webgl and dom and javascript and some 
gems of real metal code to render active and interactive content by 
producing and using events and data in the scene and njeced from 
outside the scene to produce the live simultation. And finally we do 
wish for 90fps for home entertainent.

It is not that I don't believe in dom, just that x3d and sai and 
features that work together tend to subsume dom mostly in convenience 
functions that are aimed at keeping track of events, managing event 
cascades, and actually changing the scene and event graphs at known 
predictable times.

http://www.hypermultimedia.com/x3d/Quick/SAIDEFS.htm

I think if studied, this shows that of course you can make x3d sai and 
scripts process events like the dom, but it is not easy to make the 
dom work like combination of sai and built-in supportig tools, like 
routes and defined node.field ins and outs.

http://www.web3d.org/wiki/index.php/About_the_X3D/VRML_ROUTE_statement

What are the real differences between the x3d sai and its supporting 
tools and (x)html dom plus css amd other prospecive interfaces? How 
does an author control X3D scene and event graphs using dom and css? 
Sure, we can look upstream and see what types of helper functionality 
we have coming from all w3c and even wtfwg and even scripting 
platforms. Mostly, I think we should not proceed too fast because 
there is no hurry and we happen to have more than one running x3d with 
html integration showing fantastic results with wide range of x3d 
content. With this much success we can step back and take a good look 
at our target (x)html platform and what it needs to be on the w3c 
standards-track to support performant x3d user code inline with 
(x)html code in an (x)html document using all possible (x)html 
components that make sense for x3d.

Thanks and Best,
Joe



----- Original Message ----- 
From: "Joe D Williams" <joedwil at earthlink.net>
To: "doug sanden" <highaspirations at hotmail.com>; 
<x3d-public at web3d.org>; "John Carlson" <yottzumm at gmail.com>
Sent: Friday, June 10, 2016 4:56 PM
Subject: Re: [x3d-public][x3d]V4.0 
Opendiscussion/workshoponX3DHTMLintegration


>>   The app will be installed in your browser,
>
> basic x3d demoted to an app? I would believe in an X3D scene and 
> interaction coded and run as an app, but not basic X3D as an app.
>
>> I think that “Downloading a big set of scripts” is the wave of the 
>> future.
>
> then the future sucks. Already the web is being ruined by every 
> friggin' page downloading tons of crutch js to provide some 
> convenience abstraction(s) of the DOM. Nothing more fun than putting 
> those script calls in the head, or tail and like the author having 
> to choose between platforms depending upon which js shim is in use 
> with that browser, or having several javascript developers competing 
> for your choice.
>
> At some point in the past we thought that by defining levels and 
> components that an X3D browser could just download extensions and 
> thus keep the basic download for the plugin smaller. This did not 
> work.
>
>>  Uh, what else?
>
> Well, to take a real hard look at what we want to provide as a 
> native implementation. Sure there is lots of new stuff, like what 
> you are working on, and if we do it right then the interfaces are 
> all there.
>
> So, I think we should really consider how x3d syntax and user code 
> structures can change to really fit in with html, DOM, and CSS with 
> the idea that we are aiming at browser support by native code, not 
> addons. We have seen that it is very possible to create something 
> worthwhile with just some simple syntax details and javascript. The 
> html browsers have really stepped up with much better support of 
> 'standard' javascript and DOM and other xml technologies so to me 
> there is no reason not to aim for an <x3d> ... </x3d> environment 
> where we don't need to depend on a couple of different js and other 
> shotcut schemes to get it to go big time.
>
> All Best,
> Joe
>
>
> ----- Original Message ----- 
> From: "John Carlson" <yottzumm at gmail.com>
> To: "Joe D Williams" <joedwil at earthlink.net>; "doug sanden" 
> <highaspirations at hotmail.com>; <x3d-public at web3d.org>
> Sent: Saturday, June 11, 2016 6:48 AM
> Subject: RE: [x3d-public] [x3d]V4.0 
> Opendiscussion/workshoponX3DHTMLintegration
>
>
> I think that “Downloading a big set of scripts” is the wave of the 
> future.  It’s just that you’ll do it for install and updates and not 
> every time you want to run an app.  The app will be installed in 
> your browser, phone or mobile, and you’ll be able to update as 
> desired, or when the content developer wants you to.  JSPs, JSF, 
> Struts (back-end dynamically generated HTML5) etc. will go away, and 
> you’ll be left with JSON, HTTP/WebSockets, REST and perhaps XML 
> across the network. Network back and forth will actually go down. 
> The division between Apache for static content and app servers for 
> dynamic content will become more marked.   The thing we want to be 
> able to do is figure out what the standard for dynamic 3D content 
> is.  If it’s just DIS, that’s OK—let’s bring it to the web.  If it’s 
> SAI, let’s bring that to the web.  Let’s be sure we support H-Anim. 
> Uh, what else?
>
> John
>
> Sent from Mail for Windows 10
>
> From: Joe D Williams
> Sent: Friday, June 10, 2016 3:25 PM
> To: doug sanden; x3d-public at web3d.org
> Subject: Re: [x3d-public] [x3d]V4.0 Opendiscussion/workshopon 
> X3DHTMLintegration
>
>
> But I don't think this is the point for now. It seems to me we have 
> to
> think long term and figure out what will be 'bulit-in' capabilities
> for an html browser running in an environment where <x3d> ... </x3d>
> parts are processed without the need for external scripts. I think
> downloading a big set of scripts just to get the thing running 
> should
> not be necessafy. Then the choice becomes what level of 'built-in'
> convenience and automation do we want to provide.
>
> Thanks,
> Joe
>
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>