At 1:40 PM 4/19/95, Mike Roberts wrote:
>First, assume that all of the browsers implement some form of "external"
>interface. This interface can be used to hook up an interaction engine to the
>browser. The browser and the interaction engine(s) are seperate peices. You
This makes sense. Putting the interaction engines in the browsers would
make them difficult to write, not to mention big, bulky, and in general
Microsoft-ish. :)
>Compilation/interpretation of the scripts occurs at the "client" - on the same
>machine which is running the browser, not at the "server". We guarentee similar
I think one can also make a good case for why the interpretation should be
done at the _server_ and not the client, for two reasons (as I see it):
1. It means the browser is responsible for keeping other browsers in sync
when a scene is being modified while being viewed by other browsers. You
can either have the browser do it all by itself (which would be quite a
task), or you have the server receive and redisitribute the update, in
which case you're involving the server again anyway.
2. It makes it impossible to have an object "behave" when it's not being
browed by anyone. Maybe I want an object to monitor some condition in real
time and change itself if a certain condition occurs. If that condition
occurs and nobody's browser is running the behavior script, you miss that
occurance.
>behaviors by transmitting source, as we do with VRML, rather than bytecodes or
>other similar stuff (though there is nothing inherent in this approach which
Why does this guarantee similar behavior any more than if the behavior
code, running on a server, transmits the same set of changes to the scene
graph to all clients? The changes have to be transmitted to all clients
regardless of where the changes originate (on a server or on a client) so
it's not a bandwidth issue.
I do admit I like Mike's ideas but they don't seem to cover ALL
possibilities. On one hand, using the server for the scripts would
eventually overload the poor server as people built complex VRML worlds,
but on the other hand the ability to have objects execute behaviors even
they're not being browsed opens up some interesting possibilities.
-- [email protected] In the end, there can be only one. http://www.msen.com/~invid - Ramirez, "Highlander"