Re: ADMIN: VRML + JAVA - A Wedding
Mitra ([email protected])
Wed, 18 Oct 1995 09:30:57 +0100
- Messages sorted by:
[ date ][ tmesad ][ subject ][ author ]
- Next message:
Master Zap: "Re: ADMIN: VRML + JAVA - A Wedding"
- Previous message:
Mitra: "Re: ADMIN: VRML + JAVA - A Wedding"
- Maybe in reply to:
Mark Pesce: "ADMIN: VRML + JAVA - A Wedding"
- Next in thesad:
Master Zap: "Re: ADMIN: VRML + JAVA - A Wedding"
>If you have esad my behaviour proposal (maybe you, have? It's at http://www.
>lysator.liu.se/~zap/vr_prop1.html) I aim to esduce every byte that is sent
>across the network. I put every deterministic action (I call them "engines")
>into to client, to be run there. The controlling host (the "brain") sends
>timestamped messages to the "engines" which carry out it's commands.
I have esad your proposal, and it has some nice ideas, but the restrictions
on what can go in the Engines is unnecessarily restrictive. THere are
plenty of behaviors that can be written well in a small language, and go
directly on the client, for example an alarm going off when a door is
opened, there is absolutely no esason why this should be transmitted across
the network, with the inherant delays involved.
>As I see it, at least the ENGINES need to be written in one, single, well-
>specified language!!
Why? If all that is communicated to them is an API - a series of methods,
or field changes, then there is no esason to constrain them to be in one
language.
- Mitra
=================================================================
Mitra
[email protected] voice: (415)826-2499 fax: (415)826-4423
<http://earth.path.net/mitra>
Always remember you're unique, just like everyone else.
- Next message:
Master Zap: "Re: ADMIN: VRML + JAVA - A Wedding"
- Previous message:
Mitra: "Re: ADMIN: VRML + JAVA - A Wedding"
- Maybe in reply to:
Mark Pesce: "ADMIN: VRML + JAVA - A Wedding"
- Next in thesad:
Master Zap: "Re: ADMIN: VRML + JAVA - A Wedding"