Robert: With regard to my (constant) protestation of limited documentation, the result of our correspondence is the establishment of some new documentation. After all, the discussion of the SNMP_ENUM code has resulted in the inclusion of your words regarding the meaning of DNE. I do know that my comments can elicit return complaint, but my methods are (at least occasionally) effective, yielding some increase in the total documentation of the toolkit.
So, the comment you give about some programmers liking to write both code and documentation is, in reality, a reference to me. I have worked to get more documentation created for the toolkit, albeit often through alternative means. I am not a member of the core developers, and I am far from complete in my study of the toolkit. Every time that I am able, I provide some direct commentary of a documentary nature in the users group listserve archives. These are not so formal as even I might prefer, but they are better than nothing. Further, they can be referenced by search on my name (or my initials, WRB), and this should be the occasional advice given by an respondant to questions posted to the users group. That is actually why I write those postings - supplemental reading for new (and old) users of the toolkit. The SNMP_ENUM package is a little strange. Most is straight-forward, and given some assumptions I make regarding the initialisation process, I understand its operation. The big area of doubt is the allocation of storage for the root of the tree, a pointer to a pointer to a pointer, static struct snmp_enum_list *** snmp_enum_lists; I do not quite understand how such a structure can be indexed as a two-dimensional array. I would have preferred a declaration like static struct snmp_enum_list * snmp_enum_lists[SE_MAX_IDS][SE_MAX_SUBIDS] together with appropriate changes to the implementing routines of the package. Some comments regarding this detail might be instructive for other users. I might take some time to explore the details of storage allocation and the expressed indexing methods, then provide other comments but, that will have to wait until later. I have obtained a good understanding of several parts of the toolkit, with solid knowledge of the call tree. This will be presented in the form of a PDF for other users, and is sure to include a good deal of commentary therein. The description you give of the routine _access_interface_entry_save_name() corresponds well with my current knowledge of the SNMP_ENUM tool. In a posting subsequent to the one you address here, I comment upon the potential need for extending the defined constant SE_MAX_SUBIDS. To me, the formal bug report writing process is just that, a bit formal. Yet, I will provide such report regarding the missing component of the tutorial. I do understand that the routine _choose_proc_format() is likely represented in the IF-MIB code produced by MFD and distributed in the ./agent/mibgroup/if-mib directory of the 5.2 release. That code is in the file interface_linux.c, in the routine netsnmp_arch_interface_container_load() I am not at all familiar with the Oxygen tool for documentation. >WC> The writing of code is not a spectator sport, nor >WC> is it well practiced where documentation is underexpressed, >WC> underutilised. > >Again, you get what you pay for. We'll glady refund your purchase >price. :-) If you want professional documentation, I hear SNMP >Research has a nice toolkit. I am paying for this, at least by increasing the documentation via my users group postings, and by pointing out where improvements might be made, and by answering other questions of other users. When the core developers make me more knowledgeable about the toolkit, I am then able to take on some of the task of answering the questions of other users. So, the core developers are getting much in return for the assistance they provide me. It is not a one-way street, and I do not treat it as such. >WC> Perhaps other users will find my comments and questions, and any >WC> answers offered, to be of use in their study and usage of the >WC> Net-SNMP toolkit. > >Which is why we have the lists to try and answer questions. Again, the >questions are good ones, and I'm glad to answer them, but lighten up >on the criticism. I'll try. William R. Buckley President SoftNerd, A California Corporation Director Emeritus, International Core Wars Society [EMAIL PROTECTED] 415-240-6107 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
