[MUD-Dev] C&C and Event Rescheduling

[Jon A. Lambert]

> From: clawrenc at cup.hp.com
> Subject: [MUD-Dev]  C&C and Event Rescheduling
> "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
> >> From: clawrenc at cup.hp.com
> 
> 
> >The burdens of attribute detection are difficult.  How does one
> >detect the difference between:
> 
> >ObjectA method ()
> >{
> >   x = ObjectB.attrX;      // a direct reference
> >   y = ObjectB.GetattrY(); // an indirect reference through accessor
> >                           // perhaps a derived attribute?   }
> 
> This is part and parcel of rolling the base implementation of base
> types to individual objects whicha re then composited to form norma
> MUD objects.  Thus a base object might hold the code to a method, or
> to an attribute.  Real MUD objects are then assembled under the covers
> from collections of these.
> 

Aye, just poking your model to make sure it's still cheddar and not 
swiss. ;)  

I still want to pass the whole object.  I have just reread Shawn's 
posting on the attribute flags within the DB subsystem.  I think this 
may be a good solution to resolving some unnecessary C&C failures 
(those where different attributes have changed).  I have to chew on 
this awhile though. 

> >Another possibility is for the DB manager to push the requesting
> >events unique handle onto an interested parties list along with a 
> >CRC.  
-cut-
> A change counter seems cheaper.

Hmm, could even be a 8-bit wrapping counter on each attribute/method 
forming a object signature string of sorts.
 
> >You also mention somewhere below about how some objects undergoing a
> >state change will propagate/generate events (likely asynchronously).
> >I see these objects being very similar and/or handy with IO. Maybe
> >it's possible for either the DB manager or the VM to post the object
> >state change events to the event scheduler after the  point of a
> >successful transaction commit.
> 
> This is exactly what I do.  Diagrammed:
> 
>   Event Q starts execution. 
>   Event Q modifies object X (Object Y is interested in changes 
>     to X (this is an entry in X's C&C stanza)).
>   Event Q logs an event R.
>     Event Q is added to R's C&C stanza.
>   Event Q attempts to C&C and succeeds.
>   The changes to X are commited. 
>   All IO is released.
>   Q's C&C stanza is read (a list of items to process post C&C).
>     Event R is sent to the Dispatchor to be logged as an 
>       event to process.
>     A new event S is similarly logged to send an "I-HAVE-CHANGED" 
>       message to Y from X
>   Q is flushed from the system.
>   The next event starts execution.  
>

In all my previous postings, I have been coming from a DB viewpoint.
I am currently doing the language/VM design, so this current batch
of rethinking comes from that view point.  I really must go back and
reread the watcher/spoof threads.  In your diagram Object Y in 
particular interests me (and probably GooGoo too).  Do you have plans
to have an "in language" construct to explicit define Object Y as 
a watcher of Object X?
 
> >This might require another special method/object language construct. 
> >It would handle indirect state changes as long as the room container
> >is the primary propagator.  And yes, even a temporary "neighborhood"
> >object could be born from the commit and die at the end of it's state
> >change method *boggle*
> 
> The problem is that state change messages should not be confiened to
> rooms, or be sourced from rooms.  Consider the old case of the the
> Great God GooGoo and his associated relics.  It didn't matter where in
> the land a relic was activated, GGG knew.
> 

GooGoo has interest in an explicit object(s) state.  Yet rooms/others 
only have interest in contacting objects.  How to define within a mud 
language?  Or do all objects have this implicit ability?  Or are 
objects only interested if they provide a particular method to listen?
Once again I suspect we've had this discussion before and my synapses
have reconfigured.  Why can't my mental search engine be more like 
Yahoo? 8)

> Extemporaneously creating a neighborhood for the collection of objects
> which need to be messages on the state change is an idea worth
> thinking about tho, even if the implementation derives doen to just a
> list or table.
>

The neighborhood thread was mostly way over my head.  It has lead to 
strange thoughts of lists of points within simple circles along with 
LOS detection between the center and outlying points.
 
> >You could go to a pure event model, where ALL method references are
> >considered object messages which are dispatched as events.  I have
> >doubts whether any sort of application transactional integrity could
> >be easily achieved with this approach, unless there is a strong in
> >language mechanism in place.   
> 
> <shriek!>  Could be done, yes.  Proving logical security etc is a
> nightmare.  No thanks.  <run> 
>

Circuitry design eh?  

In my language/VM model:

1) Event = application consistent transaction as defined by the mudlib 
coder.
2) Events are initiated whenever a event method is called.  An event method
call is pushed onto the execution queue and control resumes to the next
statement within a given VM stack.  Thus event method calls do not "block"
and never return.
4) Event methods may call any number of regular methods or event methods. 
5) Native server methods exist of both types and the reverse is also true
The server provides interface usable by mudlib coder.  'class character 
implements user { bleh }' (BTW thank you Java for this useful concept)


JL
-
"The environment may require conventions be maintained beyond those required
 for portability."  -- Scott Nudds, in comp.lang.asm.x86  
______