6,566
edits
Recommended Property Tree Enhancements: Difference between revisions
Jump to navigation
Jump to search
Recommended Property Tree Enhancements (view source)
Revision as of 15:13, 9 March 2016
, 9 March 2016Switch to {{flightgear url}} and {{simgear url}} to fix the broken Gitorious links.
m (Link to special directory articles) |
(Switch to {{flightgear url}} and {{simgear url}} to fix the broken Gitorious links.) |
||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Out of date}} | |||
{{Template:RFC Navigation}} | {{Template:RFC Navigation}} | ||
| Line 9: | Line 10: | ||
While this flexibility can be tremendously appreciated from a user's point of view (because it makes it so much more intuitive and easy to use the property tree) this very flexibility (that is, the lack of typing-requirements and data-integrity enforcement mechanisms) can be considered to be a troublesome factor when it comes to ensuring (and optionally also enforcing) proper internal sim state to guarantee valid state for critical variables that may seriously impact simulator performance. | While this flexibility can be tremendously appreciated from a user's point of view (because it makes it so much more intuitive and easy to use the property tree) this very flexibility (that is, the lack of typing-requirements and data-integrity enforcement mechanisms) can be considered to be a troublesome factor when it comes to ensuring (and optionally also enforcing) proper internal sim state to guarantee valid state for critical variables that may seriously impact simulator performance. | ||
Thus, data flow dependencies need to be formalized and made '''explicit''' [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18066.html] in order to help FlightGear become more structured in its housekeeping department. Implementing these suggestions will automatically also help in other areas that are currently limited by FlightGear's current model of internal state management, such as for example by making it easier to implement support for dynamically switchable aircraft (for details, see [[FlightGear Sessions]]). | Thus, data flow dependencies need to be formalized and made '''explicit''' [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18066.html] in order to help FlightGear become more structured in its housekeeping department. Implementing these suggestions will automatically also help in other areas that are currently limited by FlightGear's current model of internal state management, such as for example by making it easier to implement support for dynamically switchable aircraft (for details, see [[FlightGear Sessions]] or [[Reset & re-init]]). | ||
In addition, this very meta information will also help make FlightGear more easily parallelizable: | In addition, this very meta information will also help make FlightGear more easily parallelizable: | ||
| Line 80: | Line 81: | ||
== Introducing "Managed Properties" == | == Introducing "Managed Properties" == | ||
{{FGCquote | |||
|1= Making the property tree thread-safe is an interesting but a very daunting task since properties are (ab)used in so many ways.. :) I have a soft spot for using multi-buffering to support concurrent readers with concurrent writers, but for something as unstructured (in terms of who writes where) as this I'm at a loss to see how or if it could be applied. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34797127/ | |||
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...)</nowiki> | |||
| author = <nowiki>Anders Gidenstam</nowiki> | |||
| date = Jan 26th, 2016 | |||
| added = Jan 26th, 2016 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= the property tree as it is currently is in need of some rework because of the ownship (single desktop aircraft) approach. This is easier than it sounds - basically most of the property tree becomes part of the aircraft and only a few items are shared. This will also allow the switching of aircraft. The reason to consider this now, and maybe not implement it, is to ensure that the design will support this when it is time to implement it. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34631875/ | |||
| title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki> | |||
| author = <nowiki>Richard Harrison</nowiki> | |||
| date = Nov 19th, 2015 | |||
| added = Nov 19th, 2015 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
The idea is to introduce so called "managed properties" for crucial runtime state, in order to optionally ensure, enforce and maintain integrity of such state variables by using additional meta information to apply data-integrity requirements, as well as access privileges to prevent important runtime state from being mutated by non-authorized components or invalid data. | The idea is to introduce so called "managed properties" for crucial runtime state, in order to optionally ensure, enforce and maintain integrity of such state variables by using additional meta information to apply data-integrity requirements, as well as access privileges to prevent important runtime state from being mutated by non-authorized components or invalid data. | ||
| Line 113: | Line 138: | ||
* "unit" to directly keep track of the unit of a numeric value and optionally ensure that only values of same unit are written to a variable (currently, units are merely by convention tracked using a corresponding suffix) (also see: [http://sourceforge.net/tracker/?func=detail&aid=1241948&group_id=19399&atid=369399]) | * "unit" to directly keep track of the unit of a numeric value and optionally ensure that only values of same unit are written to a variable (currently, units are merely by convention tracked using a corresponding suffix) (also see: [http://sourceforge.net/tracker/?func=detail&aid=1241948&group_id=19399&atid=369399]) | ||
* "min"/"max" attributes to define valid ranges for numeric values | * "min"/"max" attributes to define valid ranges for numeric values [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg10993.html] | ||
* "stepping" attribute to define valid stepping for numeric values | * "stepping" attribute to define valid stepping for numeric values | ||
* "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 | ||
* " | * "wrap/mod" - to specify whether a value overflow means to flip back to the 1st valid state [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg10993.html] | ||
* "notnil" - value may never be empty/unset | * "notnil" - value may never be empty/unset | ||
* tie restrictions ? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00717.html] | * tie restrictions ? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00717.html] | ||
| Line 138: | Line 163: | ||
=== Permission handling related === | === Permission handling related === | ||
* "readonly/constant" for constant values that may not change during runtime (or currently: whose changes won't take effect until restart?) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19312.html] | * <del>"readonly/constant" for constant values that may not change during runtime (or currently: whose changes won't take effect until restart?)</del> [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19312.html] {{Done}} (by TheTom [{{simgear url|commit=0b197501e1cc611606b9c3728613530714539717}}] [{{flightgear url|commit=771586854b84f6824112f10f854488979e960094}}]) | ||
=== File handling related === | === File handling related === | ||