Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!wex@dali.pws.bull.com
From: wex@dali.pws.bull.com (Buckaroo Banzai)
Newsgroups: sci.virtual-worlds
Subject: Re: Who says what to whom (was Re: VR Protocols.)
Message-ID: <7569@milton.u.washington.edu>
Date: 14 Sep 90 18:14:34 GMT
References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu>
Sender: hlab@milton.u.washington.edu
Organization: Bull Worldwide Information Systems Inc.
Lines: 51
Approved: hitl@hardy.u.washington.edu



In article <7523@milton.u.washington.edu> brucec%phoebus.phoebus.labs.tek.com@RE
LAY.CS. (Bruce Cohen;;50-662;LP=A;) writes:
   1) The object and the building negotiate the list(s) of attributes they will
      communicate.  This is the technique used in standard interfaces which

Right - we tried this.  The theory is good, but the problem is that the
implementation required a *lot* of message interchanges.  Think of the
baseball-approaching-the-bat vs. the airplane-approaching-the-gate.  At what
distance do you communicate what information?  I suppose with faster
machines we'd be able to do more of this, but I'm not happy with the
"negotiation" approach.

      One requirement of this approach is that there be a bounded
      list of possible attributes, and that there be some minimal list of
      attributes that can be relied upon to be present.  Then the party

Right - this is how we got topheavy superclasses.  You have to play this
balancing game between having all objects know a lot about objects'
structure or you have to have a very intelligent way of handling missing
attributes. 

      If the possible number of optional attributes is
      large, the number of such emulation strategies can also be large, and
      that's where this scheme can break down.

Number of strategies?  I'd be hard-pressed to come up with *one* general
strategy.

   I don't see how to make the knowledge sets in two separate frames impinging
   on each other for the first time mesh.  I guess I'm not sure how you mean
   to relate the objects and the frames.

OK - the idea was not to have each object have KR frames, but to have there
be a system of knowledge about the world to which all objects could refer.
That is, if I'm a ball object and I'm about to impinge on a bat object, I
know that this object is of type T (or one of its subclasses) and I know
where to look in the knowledge net for information about objects like that.
Once I've inferred some things about this type of object, I can construct a
request of the bat.

The idea of this sort of implementation is to prevent what is essentially
"real-world" knowledge from having to be part of objects' structures and
also to avoid having objects know too much about how other objects are
implemented.

--
--Alan Wexelblat                        phone: (508)294-7485
Bull Worldwide Information Systems      internet: wex@pws.bull.com
"Politics is Comedy plus Pretense."