Hi folks,
I’m looking for guidance on how one might name modules that potentially have long names based on a deep API hierarchy.
For example, consider an API hierarchy that looks like this
management > traffic group > mac_masquerade_address
One could name the module
management_trafficgroup_mac_masquerade_address
But that’s just terribly long. Does anyone have any guidance from experience in naming “long” modules?
Thanks,
tim
Is there a multitude of actions that happen at the management > traffic group > * point? can all of those be handled by one module, or will each action require it’s own set of options?
I’d probably look to shrink some of the names down a bit, mgmt_tg_mac_masq_addr or something like that.
Within the general product, is there any other place that a mac_masquerade_address could be configured?
I think that in this particular case I could have a module_tg module that is able to field all configuration options.
There are other apis that, on the surface sound familiar, but each has it’s own specific configuration options. For example, an api endpoint for a logging configuration may have multiple destinations (syslog, splunk, arcsight, etc) but each of those has its own configuration options.
I suppose for those I could use a type, name, or destination field and have an “options” key for the options specific to each destination? I feel like I would be repeating myself if I were to have a module_syslog, module_splunk, module_arcsight, etc instead of a module_log that supported all of them.
To the best of my knowledge, the mac thing is only used in this api.
-tim