Simple Shared State
This proposal is for adding simple shared state to VRML.
Date: 21 September 1995
This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
Mitra <mitra@mitra.biz>
Outline
This proposal shows a way of adding a simple shared state to VRML.
It is presented at three levels
-
A trivial expression of sharing state, not dependent
on the Behaviors API or the Network
-
An implementation of (1) dependendant on the Behaviors
API
-
An implementation of (2) dependendant on a Network protocol.
It should be possible to rewrite (2) and (3) based upon a different Behavior
API, or to rewrite (3) based on the same Behavior API and a different Network
protocol (e.g. DIS).
Dependencies
-
Adding shared state to the VRML
At the simplistic level, we'd like authors to be able to trivially specify
that some collection of State is shared. To do this, we need to specify
two things. What to share and how to
share it .
-
What to share
We need to specify what to share, because any world that shared ALL its state,
would grind to a halt waiting for the network. It is a skill of the author to
decide what should be shared in order to balance the need for consistency between
worlds, with keeping network bandwidth reasonable. This proposal builds on the
seperate Interface proposal, by specifying
which of the interface fields in the Separator are shared. There are a number
of syntactically different - but semantically equivalent - ways of doing this,
a standard interface looks like:
Toaster {
isA Separator
fields [ SFColor READ sideColor SFBool READWRITE handleDown ]
..... # Geometry goes here
}
One way of extending this would be to modify the keywords, for example:
fields [ SFColor READ SHARED sideColor SFBool READWRITE SHARED handleDown ]
How to share it
We have to specify how to share objects because the client has to have
a rendezvous point to share the objects through. This is true whether we
use a Multicast model (we need the Multicast group) or a Client-Server
based model (we need the server address). Rendezvous points could happen
on three levels.
-
Once - all objects in all worlds use the same rendezvous point.
This obviously has huge scaling problems.
-
Once per world, all objects in that world use the same rendezvous point.
This would probably work, but might be a problem for complex worlds
with a lot of objects where we want to serve them from different servers.
-
Once per world per object
this will scale better, but requires the author to specify more per
object.
To balance between (2) and (3), I'd suggest supporting a per world "How-to"
with a per-object override. The per-object override would look like.
DEF MyToaster Toaster {
isA Separator
fields [ SFColor READ SHARED sideColor SFBool READWRITE SHARED handleDown ]
shareMethod "worlds://foo.com:1234"
}
Where the "shareMethod" field has a URL that specifies both the method
of sharing "worlds" and the host/port (and any other paramaters), required
by that protocol. Note that the actual rendezvous point is the combination
of the URL and the name of the object - in this case "MyToaster".
At a global level we would need a seperate per-world node containing
just a "shareMethod" field, or alternatively we could make "shareMethod"
scoped by Separators, and look back up the scene-graph.
Note that this part of the proposal is not dependant on how the Browser
communicates with the Networking module (the Behavior API) or with how
networking is implemented (specified through the URI).
Shared state through the Behavior API
This proposal could be integrated with the proposal for a Behavior
API. In this case, once a Separator is active (for instance it might not be
active if hidden inside a LOD), a module is loaded to handle networking. Any change
to the State from within the browser is communicated to the networking module
via a SetField call to it, the Networking module then sends it over the net in
some way. At the receiving client, the Networking module receives this information,
and translates it into a SetField call to the browser.
Shared state through the networked protocol.
This proposal could also be integrated with the proposal for a Networked Behavior
Protocol. In this case, the Networking module will register with the server at
the point where the state is to start being shared, and then send the updates
using the network protocol.
URL: http://www.mitra.biz/vrml/vrml2/vrml-sharedstate.html
Mitra <mitra@mitra.biz>