Re: New SNMP function names
| From: | Harrie Hazewinkel | Date: | Thu, 05 Dec 2002 13:40:19 +0000 |
| Subject: | Re: New SNMP function names | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-92119@lists.php.net to get a copy of this message | ||
On Thursday, December 5, 2002, at 02:13 PM, Derick Rethans wrote:
On Thu, 5 Dec 2002, Harrie Hazewinkel wrote:I had done something similar in the past, but had various problems. The current approach is easier and allows people already to use SNMPv3 features with a reasonable change in their scripts. Also I believe that approach needs some change in NET-SNMP which I have not done yet.Why didn't you introduce this right away then, if this would be the recommend way then we don't even need the snmpv3* functions.[1] Function names for user-level functions should be enclosed with inOK, I will admit the '_' is then OK, but I rather do not use it in this case, since I would like to use that for a more session oriented functions. As an example: $sess_v1 = snmp_session(1, "localhost:161", "public"); $sess_v3 = snmp_session(3, "otherhost:161", "username", "seclevel",the PHP_FUNCTION() macro. They should be in lowercase, with words underscore delimited, with care taken to minimize the letter count."auth_protocol", "auth_passphrase", "priv_protocol", "priv_passphrase");$vara = snmp_get($sess_v1, "sysUpTime.0"); $varb = snmp_get($sess_v3, "sysUpTime.0");
I repeat, I added that one in order to have for _ALL_ existing functions an SNMPv3 variant. That eases the efforts of upgrading existing scripts and avoiding the FAQ why is there no snmpv3 version of this function.but adding an alias, because there was an alias for another function just doesn't compute to me.more of all, it's common practise with all extensions. If you find some which do not adhere to this standard, then there was taken into account a BC problem.For that alias could have been made to assist people in a migration phase.
fine.I do.This is not the case with new functions, like you added, and thus they should stick to the guide lines.I do not see any problem with the usage of 'v3'.
I suggest you do that too then.Actually, yes. But there are no aliases needed for the new functions of course.So, are you saying you should have renamed them all and keeping an alias for the BC??IMHO, the current naming refers quite clearly to SNMP version 3 or SNMPv3. Many people know this version of the protocol as SNMPv3. I beleive that the original functions did neither have an '_' character. Why is that required suddenly??Backward compatibility for those. Maybe you noticed that we added some aliases to other extensions because of this, but the snmp extension was left alone in that. AFAIK, changing or aliasing names is on the PHP 5 todo.
That is an opinion of you. What is nicely readable?? It is like taste, why you you prefer yellow over blue??argh, how can hardly readable functoin names be _more_ confusing then nicely readable function names?That is why I would like to keep it as is and how I propose it. It would be less confusing for PHP-coders. But I know this is a personal opinion.I also would like to mention that I am looking into the usage of an SNMP-session creation and then use a single variable to provide all SNMP-session info in a single variable for the 'data retrieval' functions. Therefore, I would like to reserve the use of the underscore and then without a version number.As long as you don't break BC it's fine with me.
Anyway, I suggest, you make the name changes as you all prefer. Cheers, Harrie ------------------------------------------------------------------ Author of MOD-SNMP, enabling SNMP management of Apache HTTP serverBut not thinking of users is kinda weird, and I like an example of your statement that 'easier' is dedicated by the developers as I can't think of one.I am now really curious as what is seen as easier to work with?? In to many cases I have seen that 'easier' is dictated by the developers of the tools. In this case the C-coders not the PHP coder/developer.I am even tending to give it a -1, but there is not technical reason. But there is neither a good technical reason in favour of the name change.It has little to do with a techincal reason, but more of a logical one. As all functions in PHP extensions follow the same nameing style this makes it easier for users to work with it; that's the main concern here, and that's why I'd like to change the names.