20,741
edits
Improved J661 support: Difference between revisions
Jump to navigation
Jump to search
m
→Hashing
m (→Background) |
m (→Hashing) |
||
| Line 25: | Line 25: | ||
== Hashing == | == Hashing == | ||
* hashing is already supported by the property tree itself (see SimGear library), it is in fact used internally for storing properties, so one of the easiest ways to hashing support would be directly exposing and using the hashes computed by the property tree: http://simgear.sourceforge.net/doxygen/classSGPropertyNode.html It seems, the hash code is stored as an unsigned int (private storage), see line #01758 in http://simgear.sourceforge.net/doxygen/props_8hxx_source.html So it would just be a matter of adding the following to the public interface of the "bucket" class: inline unsigned int getHashcode() const {return hashcode;} And then add a corresponding wrapper to the top level SGPropertyNode class for accessing a node's hash. Either as a static method or as a member function using the "this" pointer. Something along these lines would then allow using hashes of properties internally, which would also reduce bandwidth requirements. | * hashing is already supported by the property tree itself (see SimGear library), it is in fact used internally for storing properties, so one of the easiest ways to hashing support would be directly exposing and using the hashes computed by the property tree: http://simgear.sourceforge.net/doxygen/classSGPropertyNode.html It seems, the hash code is stored as an unsigned int (private storage), see line #01758 in http://simgear.sourceforge.net/doxygen/props_8hxx_source.html So it would just be a matter of adding the following to the public interface of the "bucket" class: inline unsigned int getHashcode() const {return hashcode;} And then add a corresponding wrapper to the top level SGPropertyNode class for accessing a node's hash. Either as a static method or as a member function using the "this" pointer. Something along these lines would then allow using hashes of properties internally, which would also reduce bandwidth requirements. | ||
* I realize that this whole idea of hashing properties makes things more obfuscated, but I guess it'd still be beneficial. Also, it would be possible to implement the "subscribe" command in a fashion so that it implicitly accepts a valid property argument and automatically responds with the computed hash value for the corresponding properties. That way, client's would not need to know about (or replicate) the hashing mechanism being used in FG, rather they would just parse the server-side response after issuing a "subscribe" command and then store hash value in a client-side map, invalid/erroneous subscriptions could be handled by a hard-coded "INVALID" response instead, which'd also be easy to parse and process in the client. | |||
* The server would sort of confirm a valid subscription by echoing back the computed hash value for the registered property listener. From an API point of view that would also be fairly clean and actually well-encapsulated, because the hashing algorithm is contained inside FG and could even change arbitrarily with any upcoming releases, without introducing breakage. | |||
= Patch prototype = | = Patch prototype = | ||