Re: BA mtg, Language justification

Mike Roberts (miker@nashua.progress.COM)
Thu, 14 Jul 1994 10:58:17 PDT

On Wed, 13 Jul 1994 17:53:02 -0700 Thomas Churchill wrote:

> What concerns me there is that I think a lot of more interesting things that
> could be done, might not- because the initial browsers lack the capability.
> Virtually every object I can think of, I would like to implement a behavior
> for, and the only way I can see to do that is programmatically on the client's
> side. I'd like my virtual radio to show the frequency as I tune it without
> round-trip requests. I'd like my virtual lamp to have an on-off switch that
> functions without round-trip delays, etc.

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.