markabrahams
commented
8 months ago Hi @drgrigorov - thanks for submitting this.
Since the MIB modules contain a vast amount of information in a single structure, there are an enormous number of finding, filtering, sorting, and data restructuring functions that might be useful to any given application. What you have here is essentially a filter and data restructure function. However, due to the vast number of possibilities for these, and the vast number of use cases we would require in the library to represent all of these, I think these kinds of functions fit better in the calling application, rather than trying to second-guess them in the library. The client application knows exactly what it data it wants and in what structure. So my preferred approached here is for the library to provide all the information in a particular format, but then to leave the querying or restructuring of this info to the calling application.
As such, I won't merge this PR, but I appreciate your interest here!
On a side note, there seems to be a small typo in the PR (the traps variable should be initialized to {} not to [])
drgrigorov
Created a funtion getTrapOIDsForModule which parses a module and creates mapping between the OID and the trap name for every object of type NOTIFICATION-TYPE.
The use if this function is for applications which receive traps and need to identify them by the name defined in the MIB file.
At the time I needed this functionality quite some time ago, I could not find this functionality in the library. I only briefly checked now and think it is still not available. The function is quite isolated and should not impact any other functionality. Of course you may decide it does not fit in the library. I think I copied and trimmed some other function to create this one.