[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <33DF968D.41C67EA6 at iname.com>, on 07/30/97 
   at 07:43 PM, Shawn Halpenny <malachai at iname.com> said:

>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?
>>
>> >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).  

This is the model I use.  

>Currently, my design states that the
>notification of change will also include what was changed in B.  

I don't do this currently, tho I suspect I could as a side-effect of
moving all the primitives (attributes. methods etc) to their own
storage units.

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

Correct.

>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 me the watch list is read by the executor as part of the C&C and
events are logged (one per object) to send the I_HAVE_CHANGED message
to each of the watchers.

>For the record, object methods appear the same to the DB as object
>attributes.  

Ditto.

>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 :>

To prevent the case where Bubba reprograms step A of a logical
sequence, and then reprograms step B to match, which opens the
possibility for a Boffo to step in and execute step A before C is
properly changed (leaving him in a logically inconsistant state), I
will be having the function of an editor object being able to edit and
commit changes to multiple objects in one C&C.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...