> > On the one hand, I concur *strongly* with Thomas that we *must* do as
> > much as possible client-side.
> ...
> > Also, I'm afraid that I have to disagree with Mike about the
> > object-binding vs. language issue. If we're going to distribute the
> > dynamic behaviour to the clients, that means we have to send that
> > behaviour to those clients somehow.
>
> Yes...
Just wanted to reitterate this again; sorry if this is repetitious and my lack of
spelling ability is annoying ;). I saw a dynamic object manipulation interface
sitting on the client side, affecting client objects sitting in the client's address
space (which have previously been downloaded from the server via
the "base" VRML we are currently discussing). Information contained in
those client objects is used as input to a language/runtime system (standard
or non-standard) which is bound to the object manipulation interface (and vice
versa).
Perhaps the client VRML app just "informs" any attached language/runtime
system that it has received a new object, and the runtime system can elect to
querry the newly received object for interaction code. The language/runtime
system would have to be fully dynamic in that it would have to be able to
accept a routine from VRML and compile/interpret it on the fly. A
flavor of Smalltalk or Lisp would fit this bill quite nicely, but as I said in the
previous post, a well defined client object maniuplation interface gives us the
flexibility to bind to almost any language, as well as some other odd things
which I would not strictly regard as languages.
-- Mike