The latest version of this paper is http://www.csl.sony.co.jp/project/VS/proposal/commentsSGI.html This paper should be read in conjunction with two others we have written: 'Extension to VRML1.0 [3]' which discusses our extensions to VRML and provides a number of examples of scripts to support behavior. 'An OO perspective on VRML [4]' this paper supports our approach by explaining our underlying philosophy
Kouichi Matsuda, Yasuaki Honda, Rodger Lea
{matsuda, honda, rodger}@csl.sony.co.jp
Sony Computer Science Laboratories Inc.
also with Central Research Center, Sony Corporation
There are several other papers not directly referenced by this memo but which are worth reading, they are '[1]' '[5]' '[6]' In this short document we try to outline our (Sony) priorities in terms of what we want VRML to be able to do, and contrast this with what we believe the SGI proposal is trying to do.
Although this is no longer possible, it is still our belief that we should:
In addition, we at Sony have a slightly different priority list:
We believe that the browser is a key component of the application, but that it is the component whose primary responsibility is 3D scene management, nothing else. Thus you cannot skip execution of scripts unless you (or the browser) really knows about the semantics of the scripts in question. Scripts are potentially the source of effects from the VRML world to the real world. A script may perform some I/O operation (for example) to communicate with the real world. Such script execution cannot be skipped for optimization purposes if it has side effects like I/O. The side effect includes any variable value update. In other words, we don't believe that your optimization scheme can be applied widely unless you have further hints from programmers.
There are several cases where we feel that your optimisation scheme may not work well. For example, one of the important optimisations that you want to do is to skip script execution for animation when it is invisible (eg the animation is performed behind you). However, it can be possible that a part or the entire animation would become visible during or after the execution if the script was actually executed. If you skip the execution of animation because it was invisible only at the start time, then it changes the semantics of the world and hence this cannot be regarded as optimisation any more.
Another case is the history sensitive input example. If the latest mouse position is always the only concern, then optimising out the script execution which depends on the previous mouse position is possible. However, if a script depends on a history sensitive input value (perhaps the input value is relative to the previous input value), then optimising out the script execution will not work very well. Again we have strong reservations about your claim that "In most cases a script does not care about the history of changes to things it depends on" (2nd para, excessive script invocation section). This may be true for trivial scene manipulations, we don't believe it is true for scripts that work as part of large scale applications such as shared interactive worlds.
Our main concern is that we think that watching variable value changes tends to cost a lot, hence should not be used as the trigger of script execution. The whole essence of an event driven model is that events are posted when they happen, they are self selecting, there is no need to check all possible events to see if any have happened.
In the same section, you say that simultaneous multiple inputs will cause (by default) the script to execute once You claim that this approach will help alleviate a percieved performance problem. However, in reality, all the object-oriented programming languages (including C++, Java, CLOS and the Smalltalk-80 related languages) do not employ such semantics and still they perform very well. Our model is quite similar to them: events are thought of as messages and scripts as methods in these languages.
We are also concerned that the logic node proposal will lead to implementation specific behaviour. For example, you discuss the case where a script depends on multiple inputs and imply that in your proposal a script will only be executed once when the inputs are set. In the TimerEvent section you discuss your notion of time and imply that the discrete sampling rate is implementation dependent. In a system that relies simply on scripts as the source of events (in your terms output values) such behaviour will be acceptable, because of the synchronous nature of your execution model. However, if we combine these two features in the presense of asynchronous external events, we arrive at a situation where it is quite possibly that in browser A the time interval allows only one value to change, whereas in browser B two values change. Thus in browser A the script is executed twice whereas in browser B it is only executed once.
With respect script re-use, harking back to our original point about using the existing computer environment. Most languages have some mechanism to support re-use. We want to use that mechanism, not re-invent our own for VRML. We accept that scripts that are bound to fields are not necessarily reusable, however existing code fragments in most programming languages that directly access fields are not necessarily reusable either. Never-the-less, languages provide other mechanisms to support re-use.
In the singe user/private copy case we require script authors to write save/restore methods. This is because we believe that the degree of persistence is different for different applications. Some do not need it at all, while others may need something as complicated as a database to store the entire state of the world and the application. In the multi-user/shared world case, persistance will be built as a meta-layer above a set of heterogeneous mechanisms, some in browsers, some in servers (if used) and some in the network protocols. Our position is to keep VRML as simple as possible. You can do that through scripts.