Back to Plaidhatter

You can follow along with my code checkins at: http://fossil.etoyoc.com/fossil/clay/timeline In between work and editing conference papers, I had a brainstorm. And that brainstorm is now Clay's new event engine. What I've come up with is that objects in Clay will all have a common ancestor who understands all of the framework interactions. Objects during creation will bolt on additional behaviors via the mixin mechanism in TclOO. And instead of invoking each other's methods directly, they will throw messages at each other through an sqlite database. The issue I'm looking at down the road is we are probably going to want larger Clay simulations to either be broken across multiple threads or even multiple servers. We are also going to want Clay simulations to run apart from a GUI's main thread. A simulation going hot and heavy could effectively block a webserver from responding. And users like to know that the program is just busy, not just locked up. The process is inspired by experiences writing simulations for the DOD using the High Level Architecture, back in the early 2000s. In HLA, objects in a simulation basically throw events at each other too. If object A throws a beach ball at object B, A formulates an event for the Run Time Infrastructure saying "I threw a ball at B". B receives that interaction, registers the hit and replies with an "ouch", also sent out across the RTI. The problem with HLA is that the RTI is baked into a really huge and nasty C++ or Java library. My advantage programming today is that I have the Tcl scripting language at my disposal. For all sakes and purposes, my code is plain text. I also have at my finger tips a really decent sockets layer, and an embedded sqlite engine. I'm essentially using an SQL database, not so much as a delivery system, but as a presentation layer

method step {} {
   set uuid [my uuid]
   my <db> eval {
select * from event where msg_rcpt=:uuid
} event {
     my event $record(msg_subject) [array get record]
   }
}
During every simulation step, each object gets to ask the database what messages arrived in the prior step. They don't have to be looking purely at messages addressed to them. Each message is also tagged with a location, so a wilderness region object can note that a new player has entered:
method step {} {
  set uuid [my uuid]
  my <db> eval {
select * from event where msg_location=:uuid
} event {
    my event $record(msg_subject) [array get record]
  }
}