Bingo. This avoids two major headaches.
One is flexibility. One of the real strengths of html is how well it
can be tailored by the user. An html file doesn't say "put in a line
at 24 point Times Roman Bold" -- it says "put in a header". It
provides defaults for what a header is (or at least, all of the
browsers I've seen do), but it does not *constrain* the user to
following those defaults. There's a flexibility inherent in that
which, I believe, contributes to how nice Mosaic feels to the user.
For our purposes, I think we need to have an OO hierarchy of objects,
with a fair bit of built-in flexibility. A "room" can invoke a given
object. That room's server should have a default version of that
object available (for users who don't have that object built into
their site's taxonomy), but that default should be easily
over-rideable by the user.
The other advantage of this model is speed. I suspect that certain
objects will prove to be very common in cyberspace (and probably not
exactly the list we predict). By keeping our model open and flexible,
we allow the user sites to maintain local copies of the objects that
*do* get used frequently. This ought to cut down on bandwidth use --
always a good goal.
The really interesting issue is that to probably want to develop
semi-standard lists of the *properties* of a given kind of object,
so that a room can specify more precisely the characteristics of
the objects in it...
-- Justin
Random Quote du Jour:
"I just discovered I'm hermaphroditic and I'm having an identity crisis.
I just discovered my mother was a necrophiliac and I'm having an identity
crisis, but it's OK because she's dead.
I just discovered my father was into bestiality, and I'm having an
identity crisis."
-- from "Final Impotence: Reasons Why I Missed the Test"