This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
Critque of Gavin's 22Nov95 behaviors proposal
26Nov95 Mitra <mitra@mitra.biz>
This responds to the first of Gavin's proposals http://reality.sgi.com/employees/gavin/vrml/Newbehaviors.html to be written in terms of events. There is a rewrite that may fix some of the problems here, but I don't have access to it today. (Gavin, please date or number your proposals)
Overview
This paper is much better (from our perspective) than earlier "data-flow" or "constraint-based" versions. Most of this document addresses detail-oriented problems with it, ones that could probably be fixed easily.
Its still incomplete, and needs a companion paper to describe the API. We believe that getting the API right is in many ways much harder than designing the nodes.
However there is a deeper issue, which is that we don't see what advantages this proposal has (from SGI's perspective) over our earlier proposal. Comparing the set of concepts in his paper with ours, we see most of the component elements appearing in both.
- EventHandlers within our proposal, equate to a ClickSensor and a ROUTE item. Conceptually the same, except that in our proposal, a "pickEvent" would be generated which the behavior could interprate any of the fields of, whereas in the SGI proposal, the ROUTEs have to be drawn between specific fields of the click sensor and fields on the logic node.
- FieldEvents within our proposal, are equivalent to a ROUTE in SGI's.
- The Logic node is equivalent to our Script Node, except for the very explicit labelling of all the input and output events. In this sense, its not really any different from earlier SGI proposals. In particular, its not possible for a script to add - at run-time - an interest in new events, all it can do is wire events into already existing fields of the Logic Node. This is fine if we presume that a script is a) static and b) known about in full detail by the author of the Logic Node. But, for example, it would preclude a script that searched the geometry and added Pick EventHandlers on all the children of a particuar object.
Detailed comments
This part addresses the questions or problems with specific parts of SGI's proposal.
- Routes
- Is "ROUTE" a Node or what? In many ways its equivalent to our FieldEvent, but doesn't have a node associated with it?
- Giving events the names of fields is not going to work well with extension nodes. Since this will require adding events, and therefore API calls, for each of the new fields. Its better to have a "SetSFVec3F" event, that takes the field name as a parameter.
- Although I realise its probably too late to change it now, I think applying events to fields of transforms is the wrong approach anyway, ideally we would be sending events to a higher level concept of an object. For example sending changing the transform field of a Seperator.
- Prototyping
- What is the "field" part of this decleration, it isn't referenced anywhere I can find.
- Changing the elements inputs of a Prototype to eventIn and eventOut is probably the wrong approach, the Prototype is an encapsulation of a sub-tree of nodes and behaviors.
- Logic: scripting
- The language field should be able to specify the language of external scripts. In some cases this information will not be available via the transport protocol (e.g. via ftp, or a local file).
- Specifying the input and output events is the biggest area of problem - its a big problem if scripts cannot add events on other objects, and cannot influence objects that they find at run time - for example send a "SetField SFColor 1 0 0" to every child of a particular node. However - to allow for some of the reuse issues you are concerned about (which I don't believe are a problem) it would be usefull to add the ability to do a redirection or routing in our proposal.
- The events are very much oriented towards field events, as opposed to pick events, drag events, and other kinds of dynamic non-field oriented events.
- "If the events...does not support": I don't understand this paragraph, if I've read it correctly, you are concerned about a script adding an event that doesn't make sense - this is the least of the worries of an incorrect script. If you are concerned about plugging and playing between pre-written scripts, then there are other less constraining ways of supporting authoring tools, for example a file associated with the script which described what inputs and outputs it required.
- Scripts
- Both schemes one and two are supported by our proposal, since the EventHandler specifies both a routine to call, and UserData. So in the case given, scheme two would be used, with the UserData specifying which field had changed.
- Incorporating support for multiple events into a single call is a good idea (although I believe it will only be a concern in a small minority of cases). This will be incorporated into the next version of our API.
- Evaluation Order
- We don't believe specifying this is neccessary, if we assume that most events are coming in asynchronously over a wire, then this concept is fairly meaningless anyway, and is a browser dependant issue.
- Ensuring that, as you say, the translation and rotation events don't get a frame drawn inbetween them, is important, but doesn't require an exectution model. All it requires is that the author has the tools to ensure synchronisation in those cases where it is required, we have these in our "RenderGroup" calls.
- I don't understand the "irrelevent events can be queued up" section.
- Asynchronous Logic
- It *WILL* be desirable to allow Logic nodes to run as asynchronous processes.
- The "start" "processEvents" and "end" calls are insufficient to do this well. Our section on initialisation has determined a need for several more calls to ensure efficiency, including the ability to load a script before running it.
- The API does not depend on the language used, it must be independant of it in order to allow it to be
implemented once in the browser and support multiple languages We've already come up with trivial ways of doing this, based on C-calling convention. This does not constrain any of the languages, or platforms, we have looked at.
- Editing the scene
- These are good questions - and I think we agree on most of the points, but not on some really important ones:
- The script must be able to Add and Remove children now - adding geometry by returning an entire SFNODE is horendously inefficient when all you are doing is adding or remviing nodes.
- We want to be able to send events directly, adding ROUTEs is not equivalent because it implies the logic node already has an output that can be plugged to the destination.
- New Sensor nodes for the pseudo-nodes are ugly, they make a simple case into a complex one.
- "PROTO Torus" ... "GenerateTorus" should probably read "GENTORUS" I assume this is a typo?
- nodeToUse = Logic { ... } .geometry: I don't think anyone else wants to be able to put Logic nodes inside field values. This implies a direct dependancy on the Open Inventor scene graph, and makes parsing MUCH harder.
- Sensors
- In general the drag sensors are a fine idea, constraining the effective movement of the pointer. These should be added to our proposal.
- The ClickSensor is OK - but we don't need it in our proposal - the EventHandler performs the same functions. I'd be happy to add any missing fields to the information in the Event (e.g. hitTexture).
- I thought SFTime gave the time in Seconds - isn't this a bit course?
- The TimeSensor is a problem - it relies on a continuous, rather than event oriented model for time, the TimerEvent in our proposal handles this better, by specifying when you will get an event, however there are sme functionality in each proposal that are not in the other, and combining them is probably a good idea.
- Interpolators
- We haven't looked at these in detail. In general they look fine, they are not really part of what is under debate here, and are as relevant to either SGI or our proposals.
- Examples
- Is "USE CLICKSENSOR.isActive" a typo
- The hard part of the Avatar example is adding new children, this part isn't addressed in the example.
- I'm assuming the seperate serverName per Avatar is just for example's sake and isn't a serious proposal of how you might do this :-)