[X3D-Public] X3dom + PROTO

[Alan Hudson]

Johannes Behr wrote:
> Hi,
> 
>>
>> First of all, congratulations for the great work you and your team is 
>> doing with x3dom. In my opinion, this could be the key for the X3D's 
>> future, specially because a plug-in will not be necesary for users.
>>
>> I have a question about one think you said in a previus e-mail:
>> " X3D reduced to the max: No PROTO or Scripting on the X3D-scene-side. 
>> All partitioning and scripting is done on the HTML side."
>>
>> What does it mean? Does it mean it will not be possible to use X3D 
>> "files" using PROTO in X3dom? Will exist and alternative way for doing 
>> the same (or similar) including passing parameters values to "proto 
>> instances"?
> 
> We propose a new experimental "HTML" profile extending the "Interchange 
> profile"
> As in Interchange (Core Level 1,  Scripting Level 0) Protos and 
> scripting are "Optional"
> 
> http://www.x3dom.org/?page_id=158
> 
> We discussed this issue in the group and choice to keep Scripting and 
> Protos out for the following reasons:
> 
> 1) Protos and (multi-language) Scripting are feature which make good, 
> conforming and performing implementation really hard.
> 2) There is already a Script-Engine for free on the browser side
> 3) With this lower set on feature different backends and native-impl. 
> should be easier compatible
> 4) Protos are an usual mix of sub-typing and aggregation which is very 
> unusual for HTML-content people.
> 5) On some closed mobile platforms is it not allowed to introduce new 
> scripting engines.
> 
I would agree with this as a good starting place.  Take the smallest 
subset of X3D needed for the domain.  Sell the whole spec as a concept 
but start small.

> We still don't have a good substitute for PROTOS yet but already have 
> some ideas.

import/export on inlines is somewhat a replacement for PROTO's.  It does 
give an interface to the file.

> Scripting is JavaScript in the HTML document
> 
> We sill support DEF/USE (and id/USE), Inlines and Routes as X3D concepts.
> (We do not know any HTML concepts which could be utilized instead)
> 
> USE references and Inlines are essential for larger and more complex 
> data and Routes are needed for per-frame updates in the retained model.
> We think we should support those and therefore support Interpolator and 
> Follower. It's not crucial for the webgl/js implementation since we have
> to do all updates in javascript anyways but it is a performance plus for 
> native/plugin backends.
> 
> The "HTML"-profile is the "minimal" supported profile in X3DOM.
> Different Backbends (e.g. WebGL, O3D, SAI-Plugin, browser-native ... 
> will support various profiles ).
> We can even see that the content profile requests or requires a specific 
> level or kind of implementation.
> However, the content author should _never_ choice a specific backend but 
> only request a specific profile.
> 
> But remember always: We do not try to solve all X3D problems with this 
> proposal and working-group.
> We try hard to ease the integration of X3D and HTML and close the gap.
> 
> This will not be the optimal platform for all 3D or even X3D 
> application. There will be always good reasons
> (e.g. Augmented Reality) for fat-clients and dedicated X3D-Systems (e.g. 
> InstantReality, FreeWRL, ...).
> 
> We try to build a good ground for Web-Applications which need some form 
> of easy access to 3D for
> there 3D-UI, Visual-Analytics- or shop-application.
> 
> regards
> johannes
> 
> 
-- 
Alan Hudson

President Yumetech, Inc.                               www.yumetech.com
President Web3D Consortium                             www.web3d.org
206 340 8900 ext 111

Open Source CAN be free, as in "free puppy"