Sony's VS + SDSC's VRBS + Mitra's
This is a first attempt to try and bring together the different proposals of Sony, SDSC and Mitra (formerly of Worlds) with the intent of producing a joint proposal that covers the goals of all three. This document should metamorphose into one or more joint papers.
This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
- First draft - Mitra - 20 Oct 95
This is an attempt to draw out what is common, and where the major differences are.
Unlike a number of behavior proposals, Sony's SDSC's and Mitra's proposals all have a basic model that conforms to ...
- A VRML object can conceptually contain both Geometry and Behavior.
This contrasts with models where there is a VRML file, and a seperate Application File.
- The behaviors may be written in multiple languages
This contrasts to proposals to do it all in a single language - usually Java
- The behavior is, or at least can be, run by a seperate interpreter
This contrasts with proposals to run the behaviors only inside the VRML interpreter - typically by significant - programming language like - extensions to VRML.
- Specifying a method to run includes a way to specify a file containing a behavior script, the language it is written in, a procedure or method in the script, and parameter(s) to the method.
- There is some way to specify an Event, and have that trigger a behavior without the interpreter continually polling the browser.
This section attempts to draw out the major areas of difference - not so much in syntax as in functionality. It tries to draw attention to all the places where it is probably not trivial to merge proposals:
- Browser communication with Interpreter.
Difference: SDSC passes its protocol across a Socket, Mitra uses library calls, Sony doesn't specify an API.
The Pros for sockets, and Cons for libraries include:
- Easily - if inefficiently - extends over networks
The Pros for libraries, and Cons for sockets include
- Much faster than using sockets
- Works well on non-unix machines
- Synchronisation can be easier - a function can return an error
- Paramaters etc ASCII Strings versus Binary
SDSC uses ascii strings for all its communication across the API, Mitra uses binary in the function calls (and for the networked version).
ASCII Strings don't require conversion of data types to internal representation (or specification of Networked Ints etc)
Binary data is much more efficient - both of bandwidth, and of CPU time because of the minimal conversion required.
The binary parameters need a more complex field because the VRML file must specify the type of the parameters.
- Fat versus thin API
SDSC's API calls are "fat" i.e. there are calls such as SetDiffuseColor, Mitra's are "thin" i.e. they are calls like SetFieldSFColor.
Pro's for fat
Pro's for thin
- The API doesn't need changing to manage new extension - "isA" nodes.
- Works well with the Interface proposal which uses extension nodes
- The API module is much less dependant on the VRML syntax.
- Object model
Sony's object model allows for manipulation of attributes inherited from parents - for example the color of a cube. Mitra believes this should not be allowed, and events should only manipulate legal fields, and probably be restricted to fields in the interface portion of a Separator.
This section attempts to list a number of minor areas of difference - or areas where it would be trivial to reach consensus (some of these might not be more less trivial!)
- Specifying the Language of the Script.
Difference: SDSC uses the extension, e.g. ".pl", Sony uses an ENUM, Mitra uses a string.
Rational: Mitra believes that the extension is a hack (may not be true on all platforms etc), a string gives better future extensability.
Proposal: Mitra proposes using a string.
- Number of parameters
Mitra's proposal has multiple parameters, Sony has one. Not sure about SDSC
Proposal: Mitra proposes multiple parameters.
- Inline scripts
SDSC doesn't allow inline behaviors, i.e. the specification of a minimal program in a node, Sony and Mitra do.
Proposal: Mitra proposes Implement inline behaviors
- Trivial behaviors
SDSC doesnt support trivial local behaviors, e.g. setting a field, Sony and Mitra do.
Proposal: Mitra proposes Implementing trivial local behaviors - we need to specify this fully.
- Event handlers
Sony implements EventHandler for pick etc, Mitra uses Sensors/Triggers/Connectors, SDSC doesnt have these.
Proposal: Mitra proposes we implement Sony style Event Handlers, but add a RegionSensor.
- Event Handler callbacks
SDSC uses explicit callbacks to named routines, Mitra wouldn't - with a thin API the calls would be of thte order of SetFieldSFColor,
Proposal: This depends on the Fat v. Thin discussion.
- Event Handler object referenced for event and result
Sony's event handlers only detect events on, or apply actions to, the object they are specifically attached to. Mitra's Sensors/Triggers/Connectors approach can detect events on any object.
Proposal: Mitra suggest that we use Sony style EventHandler nodes, but extend them to be able to detect an event on another object, and/or act on another object - with the default being for the scoped opject.
- Browser methods vs. Objects
SDSC uses browser methods such as OpGetBrowserVersion whereas Mitra uses GetField calls,
Proposal: This depends on the Fat vs. Thin argument
- Events - Enum vs. Strings
Sony uses an Enum, Mitra uses a String. An ENUM presumes we can identify all the possibilities now.
Proposal: Mitra proposes using String
- Events - on fields
Mitra allows events on fields - so that one script can watch an object or field, SDSC and Sony don't support this.
Proposal: Mitra proposes supporting these.
- ScriptType = C
Sony has a scripttype=C for internal functions -
Proposal: Mitra believe's this is non-portable but could be persuaded otherwise.
- Syntax of trivial behaviors
This needs some work on it - Mitra doesn't believe its controversial.
- Timer tasks versus Events
Sony discusses Timer Nodes but not the API to create them, SDSC discusses Timer Events, Mitra discusses neither
Proposal: Mitra proposes defining a Timer node (probably merging the 3 Sony nodes), and an API for registering timer events.
- Attributes node
Sony has an attributes node which has some important semantics, Mitra believes its functionality is/should-be handled elsewhere
Proposal: Mitra proposes ensuring the required functionality is implemented on the Separator or elsewhere.
- Event propogation
Sony proposes event propogation to parents scoped by Attributes.propogateMask, Neither Mitra nor SDSC discuss this
Proposal: Mitra proposes implementing propogation, but scoping via null events rather than a mask.
- Events handled by ALL Applets.
I believe we need to define a set of events that can be sent to all applets. This is probably not controversial, but might be - for example can we send LODIn and LODOut as events?
- Start up and Run
This needs defining, neither SDSC's nor Mitra's are generic enough to handle both cases. I believe this could be trivial? For example the call sequence
May be generic enough to support different browser styles - i.e. on some systems some of these functions could be No-ops.
- Load Interpreter for Language
- Load Applet into Interpreter
- Init Applet
- LOD In
- LOD Out
- Pause Applet
- UnPause Applet
- Unload Applet
- Unload Interpreter
This section covers areas of former differences where there is agreement on one of the approaches, or a merged approach.
- Paramater vs explicit method.
Difference: Sony and SDSC use explicit method or function names. Mitra's paper doesn't.
Solution: Mitra thinks Sony/SDSC are correct.
- Running vs. Methods
Mitra used a "SFBool Running" field, SDSC and Sony use methods,
Solution: Mitra things SDSC/Sony are correct.