Wups. I'm sorry if I gave the impression that the language binding was
intended to sit on the server side. I meant to insinuate that the object
manipulation interface and language binding exists on the client side. I was
thinking that code could be STORED in VRML objects residing on the server,
but executed on the client. Just as W3 "objects" can contain "object
references" (URLs) which are meaningful only to a particular browser (for
example, Lynx can't display GIF's, but can see the "outsides of the object"),
so can we store code in VRML objects which is meaningful only to a VRML
browser which has an interface to a particular runtime system (ie the browser
knows if the runtime system (language) attached to it via the external object
manipulation interface. Given an appropriate interface, nothing prevents
multiple (different paradigm) client interaction languages.
I think that this style of system still gives us the dynamism of having a client
language, but we don't have to deal with the language(s), at least in the short
term. I think a client language is essential for rich interactions; I just think that
we can stick in appropriate hooks, and worry about it later.
--Mike