Recommended Property Tree Enhancements: Difference between revisions

m
m (fixing syntax to match the original proposal and linux/unix style of variables)
Line 13: Line 13:
=== 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/overwrite 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. This is a theoretical nightmare from an data integrity point of view, because state may be mutated from places and by components that may -strictly spoken- have no business exercising write access for certain properties or even whole subtrees of the property tree.
 
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 component (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 mutate outside state outside their 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 ===
2,561

edits