[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

clawrenc at cup.hp.com wrote:
> 
> In <33D8DED4.41C67EA6 at iname.com>, on 07/25/97
>    at 10:15 AM, Shawn Halpenny <malachai at iname.com> said:
> 
> >clawrenc at cup.hp.com wrote:
> >>   How do you handle broadcasting state changes to other objects?
> 
> >The following is my first take on this, since until this point I had
> >only said that there needs to be some way of notifying other objects
> >of state changes:
> 
> >Post an event to call the notification method on each interested
> >object.
> 
> How do you know who is interested?  Where is that data maintained, and
> how does it get there?  Does the notification enclude what changed, or
> just that there was a change?

Object A that wants to know when object B changes asks B to tell A
when B changes.  B then saves a reference to A in the internal list
of objects that want to know about changes to B (this list is
maintained solely by B).  Currently, my design states that the
notification of change will also include what was changed in B.  That
will depend somewhat on the scheme I use to determine object change
when C&Cing--if I'm keeping track of individual attribute (or method)
changes, I might as well pass along what got changed, since I've got
the data handy.  And in that case, A will probably ask B to notify of
change in a particular attribute, as opposed to any change in B.  

All this notification is only done once an watched object has
successfully committed, otherwise failed commits would result in
wrongful notification of change.  

At the moment, I think the only entities that care about that
internal list in B is B and the DB, though it may instead be up to
the Executor (JCL's term--I'm haven't entirely hashed out that part
of the design yet) to notify the objects in that list of changes to B.  

For the record, object methods appear the same to the DB as object
attributes.  This makes changing a method the same as changing an
attribute--the C&C mechanism will take care of the contention where
Bubba is opening a door and Boffo is changing the code for opening
the door.  Only the VM cares if the contents of an attribute actually
represent an attribute or a method.  None of this is gospel in my
design yet, so I fully expect you to blast some holes in it :>

<mental note:  post about some of the related stuff in the forwarded
 "LP: How's it work" post>

> >Only a single instance of this method needs to be running at
> >a time, since the event will now handle further state changes by way
> >of the C&C mechanism and thus keep retrying the notification code
> >until it completes.  So, the event is only posted if the notification
> >method that is called is not already being executed (this is
> >maintained by a bit in a bit field within the object).
> 
> What about if an object has watches on multiple other objects?

Hurm.  What I typed isn't how it should work--confused the notification
stuff with the C&C stuff :P

As above, the Executor will run through the list of objects who want to be
notified and poke them, at which point they can all do whatever they'd
like.  There is no limit imposed on the number of watchers on an object.

--
Shawn Halpenny

"It is impossible to make anything foolproof because fools are so
ingenious."