4,400
edits
Recommended Property Tree Enhancements: Difference between revisions
Jump to navigation
Jump to search
m
Recommended Property Tree Enhancements (view source)
Revision as of 19:04, 8 March 2011
, 8 March 2011Robot: Cosmetic changes
m (Robot: Cosmetic changes) |
|||
| Line 24: | Line 24: | ||
In addition, such losely structured and organized write access to properties also raises the question of housekeeping and cleanup responsibility, once data needs to be cleaned up for example, i.e. when re-initializing a specific subsystem or possibly the whole simulator. | In addition, such losely structured and organized write access to properties also raises the question of housekeeping and cleanup responsibility, once data needs to be cleaned up for example, i.e. when re-initializing a specific subsystem or possibly the whole simulator. | ||
As of 05/2009 this is an issue that has also been discussed on the jsbsim developers mailing list, because there is currently no clear policy whether distinct components (such as an FDM) should generally only mutate internal/private state (i.e. state that is at least conceptually 'owned' by the component) or whether components should also be allowed to mutate outside state outside their own branch of the private property tree (see [[ | As of 05/2009 this is an issue that has also been discussed on the jsbsim developers mailing list, because there is currently no clear policy whether distinct components (such as an FDM) should generally only mutate internal/private state (i.e. state that is at least conceptually 'owned' by the component) or whether components should also be allowed to mutate outside state outside their own branch of the private property tree (see [[FDM engine feature standardization#Constraining Property Tree Access|Constraining Property Tree Access for FDMs]] for details). | ||
=== No concept of (exclusive) property ownership === | === No concept of (exclusive) property ownership === | ||
| Line 34: | Line 34: | ||
=== Concerning the Concept of Property Ownership === | === Concerning the Concept of Property Ownership === | ||
It's pretty obvious that this might probably also be very useful to help prepare FlightGear for a more modular and parallelized (multithreaded) future (as discussed and proposed in [http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf]), where it would be of paramount importance to provide very finely-grained access to data that may possibly require locking in a threaded environment, so | It's pretty obvious that this might probably also be very useful to help prepare FlightGear for a more modular and parallelized (multithreaded) future (as discussed and proposed in [http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf]), where it would be of paramount importance to provide very finely-grained access to data that may possibly require locking in a threaded environment, so that FG components would no longer directly write to properties (that are conceptually owned by other subsystems) but rather write their requests [=new values] to a blocking, component-specific queue, which would in turn be processed (validated, checked for integrity) by the owning component in a sequential fashion to ensure valid internal state. | ||
Basically, resembling/emulating queue-based [http://en.wikipedia.org/wiki/Software_transactional_memory Software Transactional Memory]. FlightGear components would then publish a public getter method which could be accessed by all other components to read arbitrary component-specific state, unlike updates (write access) to properties, which would only take place using a well-defined component-specific interface. | Basically, resembling/emulating queue-based [http://en.wikipedia.org/wiki/Software_transactional_memory Software Transactional Memory]. FlightGear components would then publish a public getter method which could be accessed by all other components to read arbitrary component-specific state, unlike updates (write access) to properties, which would only take place using a well-defined component-specific interface. | ||
| Line 81: | Line 81: | ||
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. | ||
== Recommended new 'types' | == Recommended new 'types' for nodes == | ||
Currently, there is no clear distinction taking place between arbitrary strings, filenames, paths, property paths or property nodes - this makes it increasingly complicated to keep track of what sort of data is represented by a particular node/string in the tree and makes it basically impossible to provide validation routines, or even come up with XML schemas [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21404.html] that might help validating PropertyList-encoded XML files. | Currently, there is no clear distinction taking place between arbitrary strings, filenames, paths, property paths or property nodes - this makes it increasingly complicated to keep track of what sort of data is represented by a particular node/string in the tree and makes it basically impossible to provide validation routines, or even come up with XML schemas [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21404.html] that might help validating PropertyList-encoded XML files. | ||
| Line 94: | Line 94: | ||
* type="string: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 == | ||
* "scope" or "lifetime" to formally describe the scope of a node as discussed in [[FlightGear Sessions]] | * "scope" or "lifetime" to formally describe the scope of a node as discussed in [[FlightGear Sessions]] | ||
| Line 117: | Line 117: | ||
* "flip-around/mod" - 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 ? | * tie restrictions ? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00717.html] | ||
* listener restrictions (max/none)? | * listener restrictions (max/none)? | ||
* max simultaneously registered active (writing) listeners | * max simultaneously registered active (writing) listeners | ||
| Line 136: | Line 136: | ||
=== Permission handling related === | === Permission handling related === | ||
* "readonly/constant" | * "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] | ||
===File handling related === | === File handling related === | ||
* "filetype:" to explicitly highlight type of file being expected/provided (i.e. "texture/rgb") - this should probably make use of standard MIME types | * "filetype:" to explicitly highlight type of file being expected/provided (i.e. "texture/rgb") - this should probably make use of standard MIME types | ||
* "default-working-dir" - default cwd if only filename specified without path info | * "default-working-dir" - default cwd if only filename specified without path info | ||