On Thu, May 7, 2009 at 10:54 AM, Staz . <[email protected]> wrote:
> Let me explain in more detail what is going on in the project at this moment > - at least not to keep you "veiled in darkness". :) Actually, it sounds to have a lot of similarities with my 'process control framework' which is also "very early stages" ;-) And perhaps you should deploy a similar strategy. 1. There are Controllers (i.e. WorldObjectInstances) in a ControlProgram (i.e. WorldZoneInstance). 2. Each Controller has X inputs and Y outputs. 3, Each Input can only be Wired (inter-WorldObjectInstance interaction) to a single Output (inter-WorldObjectInstance interaction responses).. 4. The information of where the Input is wired to stored within the Controller entity state. 5. The ControlProgrammer can modify the ControlProgram, by requesting the Controllers as ProgrammableControllers (i.e. WorldObjects). It is the same underlying entity state, and the ControlProgrammer have now access to make Wiring changes. It can also query for what Inputs/Outputs and Parameters(see below) are available. 6. Each Controller also has Parameters. 7. Each Parameter is either a ProgramParameter (i.e. charateristic) or a RuntimeParameter (i.e. for dynamically changable characteristics, such isBlind() ). 8. A third role on the Controllers is the QueryableController, which basically allows you to retrieve the internal state of the Controller for display purposes. 9. When a ControlProgram (in my case could be "WarmWater regulation to 55degrees Celsius with burn protection" ) is requested, the runtime engine (no name yet) will create a UnitOfWork and load the RuntimeControlProgram aggregate, which in turn holds the Controllers, which in turn holds their "interaction wiring" between themselves. 10. Ultimately, 'wiring' has Sources and Sinks, which are stuff like Timers, Physical Input/Output, TCP ports and some others. They are provided via the Service mechanism, as they are a lot more resource intensive a require special handling. Sources initiate the 'interaction event chain' and the 'event' spreads though the ControlProgram and eventually dies down when all events have 'died down' either from being filtered in Controllers or reached Sinks. 11. Finally, the logic of each Controller, both the Runtime role and the Programmable role, are implemented in Java, so there are many sub-types of Controllers, such as PID-regulator, HighLowLimiter, AlarmPoint, ZoneController et cetera. Programmers will add to the repoertoire of controllers, and install the "Controller types" as OSGi bundles, and the ControlProgrammer will ask services for available types. Ultimately, those shows up to the user during "programming" as tools in a Palette, to drag into the ControlProgram and be wired up. Now, I don't know about you, but I see a lot of similarities here, and I think what you are doing can be implemented with the same pieces (different names), except that you would need to make the wiring system dynamic as well, since as your characters move around you will end connecting and disconnecting with other elements in the world. Personally, I think event-driven (a.k.a write-only) systems are superior to request-response systems, and if the 'wire' is abstracted as well, the system can much easier be spread across JVMs, as a single, one-directional transport mechanism needs to be implemented. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
