On Fri, May 8, 2009 at 10:58 PM, Staz . <[email protected]> wrote:
>> 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() ). > > Ahh, now I see the parallel of my WorldObjectCharacteristics in your system. > So, the user can change Parameters and Wirings of a Controller? How > Parameters affect on Controller? Or do they only affect on > Wirings/Inputs/Outputs? "user" is a 'role' from Qi4j's point of view. An Entity can have more than one type, which may sound a bit odd. But that means that I can create entities with non-modifiable characterstics when seen from one role, yet being fully mutable from a different role. It becomes a matter of how you expose public methods in each entity type. So, in my case; a "Wire" is a connection between one 'input' of one controller to zero or one outputs of another controller. In Qi4j terms, I have not yet nailed down exactly how to model this, since I think I will need to abstract away the transport to allow cross-JVM delivery of messages from outputs to inputs. Parameters on the other hand are more not part of the dynamic and continuous flow of data, albeit they can still be wired to outputs. For instance, it is common to have setpoints (what a value should be) wired to the output of a "Curve" (an X-Y conversion along a non-linear curve) which has its input from a sensor. Still, the parameter in the end is "persistent", in that if the wire is removed it will retain the last value and will have it saved in a store. Inputs/Outputs data are not persisted. > I also thought of separating WorldObjectCharacteristics to programmed and > dynamically changing. I think my model still suits this kind of setups. Your WorldObjects (with their global applicability to all instances) are effectively shared instances of "settings". Perhaps you need to preserve memory, and that is possibly a bigger reason to not do a 'write-only' model. >> 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. > > Ahh, so Sources are the event generators. I was thinking that my > ActionBehaviours would be the ones generating the events, whenever > performing. But this event-mechanism also requires me to think about whole > time-issue (the game-world having its own time universe), since I want to > easily add events "to future". And that's why I haven't mentioned anything > about events in my original description - I am yet to properly to think > about whole thing. :) Maybe more versatile way of telling what Action > requires - right now it is just a list of required > WorldObjectCharacteristics. "Future Events" are very common in control systems. It could be anything from "Turn off Fan1 on Sundays" to "Resend Alarm notification in 1 hour if Alarm has not been acknowledged", and in previous system I have a fairly elaborate Timing subsystem for this (essentially, compute the trigger time in the future, incl save to disk, and fire expired events). I will need to have something similar in the new system. > But thank you for telling me about all > those things - it certainly made me look at things from new perspective. :) > I'll keep you updated on what solutions I've made, once I've made them - if > you're interested. Yes, please keep us posted... 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
