6,566
edits
Improved J661 support: Difference between revisions
Jump to navigation
Jump to search
Switch to {{gitorious merge request}} and {{flightgear url}} to fix the broken Gitorious links.
Red Leader (talk | contribs) (→Patch prototype: Fix diff indent) |
(Switch to {{gitorious merge request}} and {{flightgear url}} to fix the broken Gitorious links.) |
||
| Line 2: | Line 2: | ||
== Status 07/2012 == | == Status 07/2012 == | ||
<del>The original patch discussed in 09/2011 is pending review in | <del>The original patch discussed in 09/2011 is pending review in {{gitorious merge request|proj=fg|repo=flightgear|mr=28|text=merge request 28}}.</del> (now committed) | ||
== Enhancement suggestions == | == Enhancement suggestions == | ||
Referring to the code in | Referring to the code in {{flightgear url|path=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: | 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: | ||