Wes,
Thank you for taking the time to put the history of Net-SNMP's codebase to
paper. I feel that it puts why the codebase is the way it is in its proper
perspective.
After reading this very insightful essay, I feel that Net-SNMP being the
"de-facto SNMP stack" also means that it's the reference implementation of the
SNMP protocol. I will address some of the points below from that perspective.
On Mon, May 14, 2018, at 2:07 PM, Wes Hardaker via Net-snmp-coders wrote:
>
> Developing the code ended up in roughly the
> following notions/priorities:
>
> D) Ideally, compartmentalize code into files that could be included and
> excluded at will via configure flags. The mib-modules are done this
> way, as are the transports, SNMPv3 security modules, etc. You get to
> compile in only te items you need. And the mib-module's hardware
> abstraction layers (HAL) meant that the code that dealt with SNMP
> representations could be put into one file, and all the system
> dependent code could be put into OS or hardware specific files to
> implement the abstraction layers. This is what lead to directories
> of code files like agent/mibgroup/host/data_access, for example.
>
> E) We would maintain a number of back-release branches to help support
> those unwilling to move forward for one reason or another (often
> because they forked the code for internal use and the merge of a
> later branch didn't go as cleanly as they hoped). Thus, we have a
> number of back branches and LTS branches which we've maintained much
> longer than promised).
This is my vision for how the Net-SNMP codebase could be restructured to
achieve a clean code, and backwards compatibility (hopefully, the ASCII art
displays nicely on most email clients)
-------------------
| DEVICE/OS |
-------------------
|
|
--------------------
| SNMP CORE |
--------------------
|
|
--------------------------
| Communications |
--------------------------
Very briefly, SNMP CORE would contain API or function definitions that would be
used by the agents or the command-line clients. DEVICE/OS could be
implementation of functions that the agent needs to collect device or OS
information. Communications would be network connection send/receive.
>
> But, I urge caution when we collectively decide who are target audience
> is. We don't know, and have no way to measure, the usage of Net-SNMP on
> architectures it's deployed on. I could wax philosophically on why I
> think we have so little data, but won't. One major point worth noting
> is that we are the defacto SNMP stack for every operating system but
> windows. Almost.
>
> And more importantly, we don't know what APIs and what #defines are
> being used in code bases out in the wild. The original code, way way
> way back when, was not properly architected to provide a public/internal
> names space and we suffer from that still today.
We could take this opportunity to collect these information. As the saying
goes, you won't know for sure until you bring the product to market.
>
> Should we abandon them and say "from the 6.0 line we're only supporting
> X,Y and Z"? I don't know. But I do know we can't move forward without
> reopening the discussion. One of the reasons that people took so so so
> long (15+ years) to switch from UCD-SNMP to Net-SNMP is that we did just
> what I'm talking about: we broke the API in a number of places and
> people were afraid to move, even though we had configure options to
> enable as much backward compatibility as possible.
>
I think drawing a line in the sand--if you will--would be a good idea for the
longevity of the project. Forgive the shameless plug; but, one of ICEI's
mission is to help hone the next generation of developers who can continue the
development of software like Net-SNMP. A spick and span codebase will allow for
more contributors to come on board, and help address user issues. Who knows, it
might even make it easier to support older hardware.
At the same token, drawing a line on the sand doesn't mean abandon them
completely. A pick-up sports game, might be a good analogy. The supported
systems could be what the current dev team has access to. Those who wish to
support other systems, could contribute code accordingly. Ideally, in the long
term we end up with a group of people who are leads for the different supported
system who will make up part of the Net-SNMP core dev team.
--
Thanks,
Keith (pantherse)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
