Talk:Generic protocol
Future improvements
These days it would be better to revamp and unify the native/generic protocol systems and ensure that things are flexible enough to get rid of the -separate- multiplayer protocol and of the old/unmaintained C++ code, probably including most of the native protocols.
And while we're at it, it would make sense to simply use the flightrecorder system configuration to determine the properties that are relevant for MP/synchronization (and obviously replay) purposes in a publish/subscribe fashion. At the moment, we have more or less mature features and systems with different sets of functionality, that are often not very consistent or compatible from an implementation point of view unfortunately.
In general, the MP/generic/native protocols haven't really been updated in a while, because everybody is hoping that HLA support is not going to be pie in the sky [1] 
- which would address all of our needs in the most flexible fashion (eventually).
It would probably make sense to log another feature request regarding the flight recorder system - because it's all about coming up with all aircraft-specific properties (including animations etc) - so the flight recorder system is the most recent, and most modern, component that addresses the same underlying core problem, namely that of sampling aircraft-specific properties.
In other words, generalizing the system and using its data to also determine what properties to sample for multiplayer or multi-instance setups is simply logical. And the good thing is that aircraft developers would be responsible to provide and maintain the correspoinding configuration file, while ensuring that a handful of related FG features would be supported using a single file. Thus, it would make sense to come up with a list of enhancements to make some of the old/unmaintained code obsolete, such as for example:
- allow protocols to be reloadable at runtime [2]
- provide better error messages [3] [4]
- threadings support [5]
- support daemons [6]
- provide support for buffered I/O [7]
- allow HTTP/REST/AJAX/JSON to be implemented using the generic protocol [8]
- allow complete branches/folders to be replicated/synced (weather, animations, AI traffic etc) [9]
- re-implement the logging subsystem and depreciate the old C++ code
- provide the infrastructure to get rid of old/unmaintained hardcoded protocols [10]
- support a conditional PUBLISH/SUBSCRIBE mechanism (see flight recorder sampling) [11] [12]
- expose the multiplayer XDR routines and make them available, so that the unmaintained MP code can be reimplemented using the generic protocol
- expose SimGear's state machine support
- provide scripting hooks via Nasal [13] [14]
- allow multi-instance/FGPanel setups to be synchronized by just parsing an aircraft-set.xml file