On Saturday 21 February 2009, Torsten Dreyer wrote: > > Pretend Curt is in a meeting and he's given 30 seconds to > > explain the property system to smart people who have never seen > > this concept before. I've just burned my first 15 seconds with > > "Ummmm, errrrr, It's like ...., you know ...." Now all these > > smart people are scowling. Now what!?! > > I'd try this: > The property system - or property tree - represents the internal > state of all systems within FlightGear, like the flight dynamics > model. The content of these internal state variables are > presented in a hierarchically manner and can easily be accessed > through a well known API. A system may present it's current state > to other systems and let other systems change it's current state > by allowing them to write to it's own properties. > One might think of the property system as a global, normalized > communication platform. > > 13 seconds - so you have two seconds for "Any questions?" at the > end... > > Torsten
or... The property system acts as a routing interface, both between different high-level FG sub-systems and the outside world. Data that is required by one FG sub-system can be exposed in the property tree, where it can then be read or modified, either by other internal FG sub-systems, or by & for external input & output. [For example, a left banking joystick input is exposed in the property tree where it is read by the FG FDM sub-system. The FG FDM sub-system then in turn outputs an aileron deflection back to the property tree where it is then read by the FG animation sub-system to animate the aileron deflection in the 3D model.] Alternatively data [the joystick input], once exposed in the property tree, can be read and modified by an external application via the FG IO sub-system, such as an external FDM. [The output from the external FDM can then be fed back in to FG by writing it's data back to the property tree, once again, via the FG IO sub-system.] In addition to the protocols supported by the FG IO sub-system there are also telnet and http interfaces, which allow property tree data to be read and modified via these interfaces. An important feature of the property tree interface is that it can be tailored and new entries added as required. [If you wish to use a custom-written sub-system, such as your own Terrain Following and Avoidance sub-system, for example, and perhaps implemented or prototyped in Nasal,] A[a]dding new property tree branches and nodes to handle your unique data presents no problems. If you need to cut it down you can take out the examples []. You can then give examples once you've got their attention. LeeE ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
