PHP Development (SNMP) (fwd)

Hi Mike, devlopment-related messages should be addressed to php-dev@lists.php.net. The core address isn't used much and only for administrative purposes. As for your SNMP suggestions. I agree with everything you have said, including the naming issue. Since 3.0.8 hasn't gone out yet (why not Stig?) we haven't actually released a version of PHP with that funny snmprealwalk() function name. Now would be a good time to change it to avoid compatibility problems. As far as the process goes. This summary you wrote is perfect. When you want to do something, write up something like this and send it to php-dev and if nobody complains, start coding. PHP development has never really been by committee. I don't think that is an effective approach. It has always been people just writing things they way they think it should work and then later if someone disagrees we work out a compromise. Usually the guy who needed the thing badly enough that he sat down and wrote it, knows more about it than everyone else, so there aren't usually too many disagreements. The snmp module is woefully incomplete. I wrote the first version extremely quickly to solve an urgent need on a project. Very little thought went into it. I basically just read through snmpget.c and snmpwalk.c in the UCD distribution and paraphrased these into the PHP API way of doing things. -Rasmus ---------- Forwarded message ---------- Date: Fri, 21 May 1999 13:42:07 -0700 (PDT) From: Mike Jackson <mhjack@tscnet.com> To: core@php.net Subject: [PHP-DEV] PHP Development (SNMP) I am interested in contributing code to php3. Specifically, I am interested in coding for the SNMP module. First some background on myself: I am the President of TSCNet, an Internet Service Provider located in Silverdale, Wa, US. I am basically a self taught programmer and have been programming in C for about 12 years. I have been using PHP (Since PHP2) for our own in-house stuff as well as for clients. Naturally, I wanted to be able to generate web pages for doing things like monitoring our equipment using SNMP. I started using the SNMP module about 1 week ago, but have found that it seems to be missing much of the functionality that I require. I have already submitted a bug fix for snmprealwalk() that has been accepted into the CVS tree (#1423). Here are the some of the changes and additions that I'd like to make: 1. There needs to be a way to select quick_print (this is part of the ucd library and causes just the values to be returned rather than the object type information and extra stuff like hex codes for strings of 3 characters or less). This could be done in several ways: a. The snmpget(), snmpwalk(), and snmprealwalk() functions could simply be changed to always return 'quick_printed' values. (I initially implemented this on my system, but then changed to method e). b. More functions could be added (i.e. snmpgetq(), snmpwalkq(), snmprealwalkq() that set the quick_print setting. c. Another parameter could be added to the functions (after retries and timeout) to the functions that allow the selection of quickprinting. d. A php3.ini entry could determine if snmp_quick_print was on or off for all 3 current snmp functions (and future ones also). e. A function could be added [snmp_set_quick_print()] to enable or disable quick printing with a corresponding function to get the current status of quick_print [snmp_get_quick_print()]. This is the way that the ucd applications do this; however, it's not good for threads. Then again, the ucd library contains the static for storing the quick_print value, so it's not a thread ready library anyway. If the library becomes thread capable (having a value stored for each thread) then this method would also be threadable. I'm not sure which of these 4 methods is the best. Option a. could break existing code, option b seems like adding unnecessary functions, option c seems unpure, and option d seems bone headed. I'm currently thinking that option e is the best one, and have implemented this on my system and it work well. Again, this isn't thread compatable, but niether is the library. Also, even when quick_print is enabled, all character strings are returned with '"' characters around them. I propose to strip them in quick_print returns since they are being returned to php3 which knows they are a string. 2. I don't particularly like the idea that the snmprealwalk() has then name that it does. It seems to me that this was added to correct a trouble report and wasn't part of the plan for the library. I would suggest that, since it's not documented well yet, it be renamed snmpoidwalk() or snmpwalkoid(). I prefer snmpwalkoid() because it will be closer to snmpwalk() in the documentation. This is a policy decision though, and I don't know if this is approporiate, so for the time being I'm implementing both snmpwalkoid() and snmprealwalk() to both be identical. 3. I also intend on implementing snmpgetnext(). This probably has limited application, but the php3 snmp library just doesn't seem complete without it. snmpgetnext() would only seem to make sense if it returned an associated array (of one item) that contained the oid and the value. So perhaps it should be called snmprealgetnext() or both should be implemented. Or snmpgetnextoid() and snmpgetnext(). My reasoning is that if a programmer has found need to use snmprealgetnext instead of snmprealwalk, then they are doing so because they don't know the oid of the next variable (and so presumably would like to know what it is). 4. I also plan on implementing snmpset(). I think this is really important. I've already come to the point of needing it :) Of course I do this now by spawning a copy of /usr/local/bin/snmpset since it's not in the php snmp code yet. 5. The library also has function calls similar to snmp_set_quick_print for telling the library to return full or partial oids and numeric or symbolic oids. These probably won't be hard to implement. These will be implemented as: snmp_get_full_oid(), snmp_set_full_oid(), snmp_get_duffix_only(), and snmp_set_suffix_only(). 6. Also, the retries and timeout values are currently optional parameters to the functions (although not documented), these could also be set using special functions instead of being parameters. 7. It may also be possible to implement snmptranslate() and snmptable() into the library. snmptable() would require returning a two dimensional array of the information returned and would therefor be slightly harder to implement. I have applied for an account on the CVS system, and would ask that this be approved. How and who should make the design issue decisions? Should I just do what I think is best, or should I outline any changes I plan on making ahead of time? I'm a strong believer in documentation, so naturally, I'll provide that as well as examples of using the new functions. So, basically, I am offering and asking to take over code development for the SNMP modules. I don't want to tread on anyone's private domain, but I think I can do a good job making this particular section of PHP3 more useful and flexable. I use these functions in my own PHP3 programs, and I know what I would like them to be capable of doing. If you decide that you don't want to give me access to the CVS tree, you can also just tell me who to send my changes/additions to for review. Thanks for your consideration, Mike Jackson TSCNet -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net