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

[John Carlson]

Basic X3D already is an app.  It’s called a plugin presently, and it’s in a walled garden.  Do you want to stay behind the wall or not?  I did not say “basic x3d demoted to an app”.

The way things are going, with web-components, AFAICT, your users will be downloading a ton of scripts or many scripts, compressed/minified into a script package, and likely cached.  See x3dom and likely cobweb as an example.  Likely there are alternate solutions.  Providing platform support is the solution, but first, can we mix markup?  Ultimately, we are somewhat dependent on what the graphics cards makers want to do.  Do they want to accelerate 2D in a 3D context?  Accelerating 2D as an overlay on top of 3D seems to be a priority.   We shall see where VR takes us.

Sent from Mail for Windows 10

From: Joe D Williams
Sent: Friday, June 10, 2016 7:56 PM
To: doug sanden; x3d-public at web3d.org; John Carlson
Subject: Re: [x3d-public] [x3d]V4.0Opendiscussion/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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160611/88098fcf/attachment.html>