Yes...
> And *that* means we need to be
> able to assume that those clients can interpret that behaviour. And
> *that* means we need to have some sort of standard language, I
> think. We should definitely have hooks in the language, so that more
> sophisticated client-specific programs can be tied into it when
> they're available. But I think we will need a standard language for
> most of the simple work.
>
> This argues for some sort of dynamic language specification for the
> client to interpret. This means something *very* fast and easy to
> interpret, which to me means either a dialect of Lisp or Forth.
I think you should favour the human side of things here; it should
be compact and easy to write, and especially easy to design
behaviours in terms of other behaviours (i.e. a simple programming
language).
One thing that needs to be stressed is that just as people will
have libraries of shapes of objects on their clients (so that
if a scene indicates there is a fridge against the right wall,
the client's definition of a fridge is used), so will they have
libraries of standard behaviours. When people want lights to
flash, clocks to tell the time, fans to rotate, these will all
be held by the clients (once they're obtained the first time,
which could be by virtually walking into a behaviour library
or warehouse and selecting those items for home delivery).
The eco-green room of the warehouse would have tree shapes,
leaves rustling in virtual winds, etc.; the punk room would
have jagged metallic shapes, clashing sounds, and the like;
etc. So just as I can select colour patterns for my windows
and different fonts for my documents now, I'll have a choice
of styles for fridges' appearances, and selections of options
for their behaviours.
> So -- my strawman view of things. We should take Inventor's ASCII
> format as the base language. Our first cut should model just the
> static behaviour; that is, it should just implement that ASCII
> format (plus a few additions to make the distributed aspect work;
> I've got this designed in my head already). Once that's working,
> we should add the dynamic language, which would be primarily an
> object-manipulation language. It would be a dialect of Lisp, and
> focus on manipulating the scene database in various ways. It would
> have hooks for connecting to outside programs, but would be capable
> of a fair bit without those hooks. It should be as extensible as
> possible, so we don't get trapped as the language evolves. (We
> might even consider distributing the dynamic behaviours just as
> we do the static; this is a *fascinating* idea, but we're not ready
> for it quite yet.)
>
> So -- whaddaya think?
I don't see why distributing behaviours should be any harder than
distributing shapes. Is it any harder to transfer a program than it
is to transfer an ordinary piece of text? [Of course, the browser
might not be able to read/understand various behaviours, but that's
a different question.]
------------------------------------------------------------------------------
Chris.Holt@newcastle.ac.uk ftp://tuda.ncl.ac.uk/pub/local/ncmh1/nameplate.html
------------------------------------------------------------------------------
Teach me to live, that I may dread / The grave as little as my web.