Comments on (undated) SGI's "Simple Behaviors for VRML"

This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
www.mitra.biz 13 Nov 95 <mitra@mitra.biz>
The latest proposal from SGI covers both a subset and superset of the material in my most recent behavior proposals http://www.mitra.biz/vrml/vrml2/vrml-behaviors.html and http://www.mitra.biz/vrml/vrml2/vrml-api.html. It covers Prototypes, Sensors and Interpolators which my proposal doesn't - apart from the comments below, I think these are excellent additions which should be incoporated into my proposal. Gavin's Prototypes proposal replaces the Interfaces proposal Tom Meyer and I wrote. This proposal does not cover the API, which makes it hard to judge since a lot of the tough parts of my proposal have been making it work well with the API - I cover some of my serious concerns below, but detailed comments will have to wait for this part to be completed by SGI.

The three most serious problems are:

  1. It is unclear how it will be possible for an Asynchronous Applet to add events at run time, in fact the early versions of SGI's proposal specifically excluded this. Should it be possible, it looks like it would require:
    1. Compiling VRML for the logic nodes, and sensor each time an event was added
    2. Full access to change the scene graph at the point the event was being added.
    3. A connection in the existing logic node for the script doing the adding, with an SFNode output that points to the point at which the new logic node is to be added.
  2. it appears that it would require keeping the scene graph around because
    1. It appears that logic nodes can be placed inside field VALUES, as in the example
             Node {
                 input1 = NodeP{.output
             }
      
    2. Events are handled by explicitly editing the scene graph
  3. There is no support for multi-procedural applets, i.e. the equivalent of a java class, with a number of methods, so its unclear how a script adding a new event could work anyway.
  4. If an input to a script, or an output from a script, is a SFNode then this is going to lead to continual conversion between VRML and internal representations as these are copied backwards and forwards any time that they (or possibly any other input/output) change. At the very least the internal representation of these nodes is going to be being passed back and forth constantly, as compared to an event driven model where the only data passed happens when the script wishes to change something.
  5. It is unclear how multiple behaviors might be able to add children to the same node, since each behavior would have to do this through an SFNode output on its controlling Logic node, and the logic nodes would have to be hard-wired to the place where the children were being added.
  6. The comments about fan-in are really worrying, they are I believe rooted in an assumption that worlds are authored in one place by someone who knows everything that goes on, it doesn't match well with an assumption that worlds will become dynamic with objects being added to them over the network. In the typical case of adding multiple objects any of which can influence other objects (through their public interfaces) it is unlikely that the author of the "world" will know what objects influence what objects in order to specify who wins in the case of fan in.