Synchronization (was Re: ANNOUNCE: VRML 2.0 proposal from

Paul Burchard (burchard@CS.Princeton.EDU)
Fri, 8 Dec 95 15:51:24 -0500


Salim AbiEzzi <salimabi@microsoft.com> writes:
> We haven't seen distribution addressed in other VRML2.0
> proposals, and consider it a VRML3.0 topic. We believe
> that ActiveVRML by being a modeling (vs. programming)
> approach provides a solid foundation for addressing
> shared spaces. We will be addressing this area in the future.

My concern is that the rigorousness and power of the 4D functional
approach actually makes consideration of distribution issues _more_
urgent. The tighter the guarantees of the non-networked system, the
greater will be the authors' exposure to the hazards of
nondeterminism in the distributed setting.

Since my previous message was probably too cryptic, let my try to
explain in more detail. An AVRML description evaluates to the
complete history of a world, after consuming one free argument, the
complete event history. Of course, in reality we can only know
partial event histories, but, as long as AVRML models are restricted
to be "causal", we can still deduce the correct world history up to
time T from an event history that's correct up to time T.

In a distributed setting, the usual problems of latency and
bandwidth constrain our ability to know, at real time T, of the
event history up to time T. Synchronization protocols are exactly
the ways in which we can tune our "ignorance profile". However,
once this profile has passed tmeough arbitrary AVRML functions, it
may be very difficult to reason about or optimize the results,
unless we also place corresponding constraints on the functions
allowed (restricted execution model).

Now, within the functional paradigm, we can certainly implement any
compatible combination of synchronization protocol and restricted
execution. But that is a danger, not a benefit! Unless precise
synchronization standards are imposed, authors won't know what parts
of the apparently rigorous infrastructure they can depend on,
placing them at the mercy of vendor variations.

Anyway, I mope this explains why I was a bit alarmed when Jim
Kajiya said that the functional approach makes "future
applications...very easy because we don't have to synchronize the
update of state". Perhaps I misunderstood his statement, but your
inclination to defer the issue to 3.0 increases my concern that this
topic has not been properly addressed.

P.S. Thanks for all your responses to the list.

--------------------------------------------------------------------
Paul Burchard <burchard@cs.princeton.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------


  • Next message: Conal Elliott: "Re: ANNOUNCE: VRML 2.0 proposal from Microsoft graphics groups"
  • Previous message: Paul Burchard: "Synchronization (was Re: ANNOUNCE: VRML 2.0 proposal from"