20,741
edits
Improved J661 support: Difference between revisions
Jump to navigation
Jump to search
m
→Background
m (→Hashing) |
m (→Background) |
||
| Line 2: | Line 2: | ||
Establish the interface requirements for better [[J661]] support, so that J661 and FlightGear can collaborate in a more efficient, and overall better, fashion. So that J661 may connect to a running FlightGear instance in order to use simulated flight data to drive avionics simulated by j661. | Establish the interface requirements for better [[J661]] support, so that J661 and FlightGear can collaborate in a more efficient, and overall better, fashion. So that J661 may connect to a running FlightGear instance in order to use simulated flight data to drive avionics simulated by j661. | ||
Referring to the code in http://gitorious.org/fg/flightgear/blobs/next/src/Network/props.cxx My suggestion would be to extend the telnet ("props") module in FlightGear, so that we add a new helper class named "PropertySubscription" and then extend the class "PropsChannel" to get a new member std::vector<PropertySubscription*> Then, we'd add two new commands "subscribe" and "unsubscribe" to the telnet command handler, where "subscribe" would simply take the property tree string, create a new instance of PropertySubscription( property ) and then append it to the std::vector "subscriptions" which would be an instance specific member field. The command "unsubscribe" would then merely lookup the listener and delete it from the vector. | |||
The telnet-based approach is the cleanest and most portable solution without breaking backward compatibility, simply because it'd just be new commands that clients could make use of or not. However, it would probably make sense to really require each session to configure its own subscriptions (listeners actually), right? I mean, we don't want to register listeners that fire for any other sessions - only the once that actually registered the listener. Obviously, you need to respond not just with the value of the property, but also a property identifier - so that the connected client knows what property the value belongs to. And then we could either have the telnet server respond with a full "property=value" reply like: | |||
/foo/bar/altitude-ft=1500 | |||
(Which'd still be fairly verbose, but certainly better than right now) Obviously, that'd be the simplest method - fairly easy to implement without too much thinking... However, I think it would make sense to use a compressed form, e.g. one where a hash of the property is internally used - and also in responses, such as a 3-4 byte hash of the full property tree string, stored in hexadecimal- so that the response is more compressed and more efficient than using the full property string every time, i.e. consider: 7FEA=100 | |||
= Requirements = | = Requirements = | ||