2,561
edits
Recommended Property Tree Enhancements: Difference between revisions
Jump to navigation
Jump to search
m
Recommended Property Tree Enhancements (view source)
Revision as of 04:14, 26 March 2008
, 26 March 2008incorporating syntactical suggestion found in the jsbsim archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1241948&group_id=19399&atid=369399
m (incorporating syntactical suggestion found in the jsbsim archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1241948&group_id=19399&atid=369399) |
|||
| Line 1: | Line 1: | ||
== Intro == | == Intro == | ||
While FlightGear's powerful PropertyTree implementation can be considered to be the core of FlightGear's dynamic, flexible and open nature (and thus also FlightGear's success in the first place) it is more and more often getting obvious that the PropertyTree itself could benefit from an -at least optionally- more structural approach to processing (reading/writing) certain data (property tree variables), whose integrity may be directly critical for the simulator's integrity itself. | While FlightGear's powerful PropertyTree implementation can be considered to be the core of FlightGear's dynamic, flexible and open nature (and thus also FlightGear's success in the first place) it is more and more often getting obvious that the PropertyTree itself could benefit from an -at least optionally- more structural approach to processing (reading/writing) certain data (property tree variables), whose integrity may be directly critical for the simulator's integrity itself. This applies in particular in an increasingly parallel, multi-threaded environment. | ||
=== Today's Practice === | === Today's Practice === | ||
| Line 10: | Line 10: | ||
=== No access control taking place === | === No access control taking place === | ||
Currently, it is possible -and common practice- for '''all''' properties to be easily accessed (read) and written to from arbitrary FlightGear subsystems and components. In fact, it is even possible for aircraft configuration files and scripts to affect crucial internal state. | Currently, it is possible -and common practice- for '''all''' properties to be easily accessed (read) and written to from arbitrary FlightGear subsystems and components. In fact, it is even possible for aircraft configuration files and scripts to affect/overwrite crucial internal state. | ||
Encapsulation is basically non-existent for many properties. | Encapsulation is basically non-existent for many properties. | ||
| Line 58: | Line 58: | ||
=== File handling related === | === File handling related === | ||
* type="path" - value to be specified is a path | * type="string:path" - value to be specified is a path | ||
* type="filename" - value to be specified is a filename | * type="string:filename" - value to be specified is a filename | ||
=== Property Tree related === | === Property Tree related === | ||
* type="property-path" - value to be specified is a property path | * type="string:property-path" - value to be specified is a property path | ||
* type="property-node" - value to be specified is a property node | * type="string:property-node" - value to be specified is a property node | ||
== Suggested new attributes in PropertyList XML files== | == Suggested new attributes in PropertyList XML files== | ||
| Line 81: | Line 81: | ||
* "enum" for textual multi-state variables, to ensure that only valid state can be written to such a variable | * "enum" for textual multi-state variables, to ensure that only valid state can be written to such a variable | ||
* "enum-values" - store valid values for enum type | * "enum-values" - store valid values for enum type | ||
* "flip-around" - to specify whether a value overflow means to flip back to the 1st valid state | * "flip-around/mod" - to specify whether a value overflow means to flip back to the 1st valid state | ||
* "notnil" - value may never be empty/unset | * "notnil" - value may never be empty/unset | ||
* tie restrictions? | |||
* listener restrictions (max/none)? | |||
* | |||
=== Mutability related === | === Mutability related === | ||
| Line 92: | Line 95: | ||
* changes may not take effect until subsystem reset | * changes may not take effect until subsystem reset | ||
* changes may not take effect until session reset | |||
* changes may not take effect until simulator reset | * changes may not take effect until simulator reset | ||
* changes may not take effect until complete simulator restart | * changes may not take effect until complete simulator restart | ||
| Line 101: | Line 105: | ||
===File handling related === | ===File handling related === | ||
* "filetype" to explicitly highlight type of file being expected/provided (i.e. "texture/rgb" | * "filetype:" to explicitly highlight type of file being expected/provided (i.e. "texture/rgb" | ||
* "default-working-dir" - default cwd if only filename specified without path info | * "default-working-dir" - default cwd if only filename specified without path info | ||
[[Category:RFC]] | [[Category:RFC]] | ||