RE: SNMP value retrieval

php.internals

Unnamed Person

23 years ago
>Jonny, it your personal email address is bouncing. >That you know (maybe even the mailinglist email bounces for you).
Sorry for that. It seems like 1409.org is permanently gone. I've now switched to an account I have to pay for just to be on the safe side in the future. I hope this will also prevent most of the spam I received as they use SpamAssassin...
>> - SNMP_VALUEMETHOD_LIBRARY: >> - SNMP_VALUEMETHOD_PLAIN: >> - SNMP_VALUEMETHOD_OBJECT: >Do these names to be so long?? I was thinking we cane drop the >'VALUEMETHOD' or 'METHOD' part. Would that be OK and which do >you prefer??
To be honest I was never happy with these names. "valuemethod" sounds clumsy to me, but English is not my mother tongue. I'm also not happy with "snmp_setvaluemethod" as a function name. Maybe we could call the function "snmp_setvalueretrieval" and the constants SNMP_VALUE_*? I'm really not insisting on names, I only want the functionality, so every comment is welcome!
>> the value type returned by the SNMP >> agent (the ASN_* constants from the net-snmp library are also >> defined as PHP constants) >I believe the ASN_ prefix should be SNMP_ and changed as such. >That they are internally ASN_ does not matter.
Ok, I'll change these constants to SNMP_*.
>ANother thing I would like to ask is whether the group wants to support >also all kinds of types of SNMP that are not standardized and somehow >added to NET-SNMP as an expiriment. >I believe it is better to drop those, what do you think??
I don't need them. If nobody gives me some reason to keep them, I'll drop them. I'll wait for another week for some comments as I have a strange feeling that absolutely nobody else has yet commented on the patch. If no further comments are posted, I'll create a new patch. Would be a dream if gets into 4.3.3... Cheers, Jonny

Harrie Hazewinkel

23 years ago
On Thursday, May 29, 2003, at 08:31 PM, jhml@gmx.net wrote:
>> Jonny, it your personal email address is bouncing. >> That you know (maybe even the mailinglist email bounces for you). > Sorry for that. It seems like 1409.org is permanently gone. I've now > switched > to an account I have to pay for just to be on the safe side in the > future. I > hope this will also prevent most of the spam I received as they use > SpamAssassin...
I had hazewinkel.net also and maybe within the spam I did not receive or see the invoice of the domain.
>>> - SNMP_VALUEMETHOD_LIBRARY: >>> - SNMP_VALUEMETHOD_PLAIN: >>> - SNMP_VALUEMETHOD_OBJECT: >> Do these names to be so long?? I was thinking we cane drop the >> 'VALUEMETHOD' or 'METHOD' part. Would that be OK and which do >> you prefer?? > To be honest I was never happy with these names. "valuemethod" sounds > clumsy > to me, but English is not my mother tongue. I'm also not happy with > "snmp_setvaluemethod" as a function name. Maybe we could call the > function > "snmp_setvalueretrieval" and the constants SNMP_VALUE_*? I'm really not > insisting on names, I only want the functionality, so every comment is > welcome!
The names are not that important, but long ones require a lot of typing from programmers and shorter ones avoid such a change. I would 'VALUEMETHOD' drop completely.
>>> the value type returned by the SNMP >>> agent (the ASN_* constants from the net-snmp library are also >>> defined as PHP constants) >> I believe the ASN_ prefix should be SNMP_ and changed as such. >> That they are internally ASN_ does not matter. > Ok, I'll change these constants to SNMP_*.
OK.
>> ANother thing I would like to ask is whether the group wants to >> support >> also all kinds of types of SNMP that are not standardized and somehow >> added to NET-SNMP as an expiriment. >> I believe it is better to drop those, what do you think?? > I don't need them. If nobody gives me some reason to keep them, I'll > drop > them.
I would say only standard bits. The expirimental parts as as said, expirimental and many agents do not have them either.
> I'll wait for another week for some comments as I have a strange > feeling that > absolutely nobody else has yet commented on the patch. If no further > comments > are posted, I'll create a new patch. Would be a dream if gets into > 4.3.3...
Not sure, but why not. Harrie