Add generic functions for configuration

[IvanNardi]

TODO

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[IvanNardi]

This code is only a proof-of-concept to illustrate a new way to provide (more) configuration options in nDPI. The important stuff is at the end of ndpi_main.c file: the ndpi_set_config() function and the cfg_params data structure

The idea is to have a simple way to configure (most of) nDPI:

• only one function to set any configuration parameters (in the present or on in the future)
• try to keep this function prototype as agnostic as possible.

This way, anytime we need to add a new configuration parameter:

• we don't need to add two public functions (a getter and a setter)
• we don't break API/ABI compatibility of the library; even changing the parameter type (from integer to a list of integer, for example) doesn't break the compatibility

Basically ndpi_set_config() is an extended version of ndpi_set_detection_preferences() [if you prefer, we can keep this name...]

[There is a LOT of work to do to have some kind of API/ABI compatibility in nDPI (if we ever want to do that...), and the configuration might be a good (and simple) starting point...]

As example of how to extend the configuration, I added the ability to enable/disable the extraction of the sha1 fingerprint of the TLS certificates.

This logic is not new: lots of libraries already uses it

If this idea is accepted, we might remove ndpi_set_detection_preferences(), enum  ndpi_prefs, ndpi_set_protocol_aggressiveness(), ndpi_set_opportunistic_tls()....

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[utoni]

[There is a LOT of work to do to have some kind of API/ABI compatibility in nDPI (if we ever want to do that...), and the configuration might be a good (and simple) starting point...]

I think there are legitimate reasons to break API and ABI compatibility in some rare case, because there is always be an ongoing development progress and some changes might require to do so.
But as we do not have any API/ABI check in the CI, I think it is not always easy to verify that (I mean in a automated manner).

[utoni]

Basically ndpi_set_config() is an extended version of ndpi_set_detection_preferences() [if you prefer, we can keep this name...]

But why not e xtending ndpi_set_detection_preferences() and break the API/ABI for once?

[IvanNardi]

[There is a LOT of work to do to have some kind of API/ABI compatibility in nDPI (if we ever want to do that...), and the configuration might be a good (and simple) starting point...]

I think there are legitimate reasons to break API and ABI compatibility in some rare case, because there is always be an ongoing development progress and some changes might require to do so. But as we do not have any API/ABI check in the CI, I think it is not always easy to verify that (I mean in a automated manner).

Sw compatibility across releases is not the topic itself of this PR: I cited it only because it is a topic where we, historically, never paid attention and where we could likely do better.
If we are able to create a configuration API which, as a side effect, guarantees some kind of API/ABI compatibility, I think it would be nice. I stress out "as side effect" part, it is not the primary goal

[IvanNardi]

Basically ndpi_set_config() is an extended version of ndpi_set_detection_preferences() [if you prefer, we can keep this name...]

But why not e xtending ndpi_set_detection_preferences() and break the API/ABI for once?

As I said, the naming is open to discussion: we definitely could keep the old ndpi_set_detection_preferences name...

[IvanNardi]

A simpler and updated version is available #2190

[IvanNardi]

Superseded by #2249