For some custom client implementations, it would be necessary to handle custom payload fields like orthos_id. The question is, how would that be handled.
The now agreed upon way is as follows:
[x] By default, custom parameters are ignored
[ ] A --pattern X flag will be implemented which allows the user to select a hardcoded pattern - which is natively supported by the collector. It will map the fields specified in the pattern to collected data and then create a HashMap<String, Value> for the translator module
[ ] A new --plugin <PATH> argument will be added which allows users to write scripts in either bash, python or lua (and/or others) to collect certain additional data and output a json. Nazara will then read this output and try to serialize the JSON into a HashMap<String, Value> for the translator module.
You would like to suggest a new feature?
For some custom client implementations, it would be necessary to handle custom payload fields like
orthos_id. The question is, how would that be handled.The now agreed upon way is as follows:
--pattern Xflag will be implemented which allows the user to select a hardcoded pattern - which is natively supported by the collector. It will map the fields specified in the pattern to collected data and then create aHashMap<String, Value>for thetranslatormodule--plugin <PATH>argument will be added which allows users to write scripts in eitherbash,pythonorlua(and/or others) to collect certain additional data and output ajson. Nazara will then read this output and try to serialize the JSON into aHashMap<String, Value>for thetranslatormodule.