Howto:Work with the Property Tree API: Difference between revisions

Jump to navigation Jump to search

Howto:Work with the Property Tree API (view source)

Revision as of 09:04, 25 January 2012

14 bytes added ,  25 January 2012
m
→‎Modeling an API on top of the property tree
Line 24: Line 24:


There are certain advantages by using the property tree like this, because all FlightGear subsystems can easily access those "APIs" - i.e. once a certain feature is implemented and provided using the property tree, the corresponding features becomes accessible everywhere, it would no longer matter if you wanted to access the feature internally, e.g. using the property tree browser, using an XML configuration file, a Nasal script, a networking protocol or even the telnet/props interface - simply because all of these methods have access to the property tree. In other words, once a feature is implemented like this, RPC also becomes possible automatically.
There are certain advantages by using the property tree like this, because all FlightGear subsystems can easily access those "APIs" - i.e. once a certain feature is implemented and provided using the property tree, the corresponding features becomes accessible everywhere, it would no longer matter if you wanted to access the feature internally, e.g. using the property tree browser, using an XML configuration file, a Nasal script, a networking protocol or even the telnet/props interface - simply because all of these methods have access to the property tree. In other words, once a feature is implemented like this, RPC also becomes possible automatically.
The AI traffic system is working like this for example: It registers a listener callback that gets invoked whenever updates take place for the corresponding branch in the property tree (such as /ai/models).


The AI traffic system is working like this for example: It has registered a listener callback that gets invoked whenever updates take place for the corresponding branch in the property tree (such as /ai/models). So as soon as some part of FG makes modifications, the AI system is there to validate and process these modifications - i.e. in order to parse and see what it has to do. At that point, it doesn't matter any longer if you are instantiating AI traffic manually (by using the property tree browser), using a Nasal script or a telnet connection into the property tree - simply because the AI system provides an API an top of the property tree that is accessible to all FG systems.
So, as soon as some part of FG makes modifications to this branch, the AI system is there to validate and process these modifications - i.e. in order to parse and see what it has to do.  
 
At that point, it doesn't matter any longer if you are instantiating AI traffic manually (by using the property tree browser), using a Nasal script or a telnet connection into the property tree - simply because the AI system provides an API an top of the property tree that is accessible to all FG systems.


Another advantage is that there wouldn't be any changes required to Nasal or other existing code, this would be just about adding a new subsystem, making it listen to a dedicated branch in the property tree (such as /usb-hid) and processing events. This is where you'd need to map the core C++ API to property tree events, where you'd handle argument processing.
Another advantage is that there wouldn't be any changes required to Nasal or other existing code, this would be just about adding a new subsystem, making it listen to a dedicated branch in the property tree (such as /usb-hid) and processing events. This is where you'd need to map the core C++ API to property tree events, where you'd handle argument processing.
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/39652"

Navigation menu