On Thu, Jul 14, 2011 at 9:46 AM, Giuseppe Modugno
<[email protected]>wrote:
> **
> On 14 Jul 2011 at 7:38, Robert Story wrote:
> > On Thu, 14 Jul 2011 11:39:54 +0200 Giuseppe wrote:
> > GM> I have to add a variable in a private MIB. This integer variable
> represents an audio volume and it can assume values in the range 0..1000, by
> steps of 5:
> > GM>
> > GM> 0, 5, 10, 15, 20, ... 995, 1000
> > GM>
> > GM> Moreover, it can assume another special meaning value that means
> Mute (for example, -1 or -100). I'm thinking how to implement this kind of
> variable in a MIB.
> > GM>
> > GM> I know SMIv2 doesn't allow mixing enumerated integer values with
> numbers (not enumerated). But I need both functionalities: it would be good
> if the user can GET/SET "mute" status without knowing a special value (like
> -100), but he should be able to
> > GET/SET other values in 0..1000 range.
> >
> > Simply define the special enums in the mib, and the text description
> can
> > describe the 0-1000 by five restriction.
>
> Are you suggesting something similar?
>
> volumeControl OBJECT-TYPE
> SYNTAX INTEGER{ mute(-100) }
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "SET this variable in 0..1000 range
> by 5 steps, or mute(-100)."
> ::= { parentNode 1 }
>
> What does the manager say when the user wants to SET this variable to a
> value of, say, 10? I supposed the manager didn't allow setting values that
> aren't in the range written in the MIB file (and in this case the range is
> composed by a single value, -100).
>
> Is this approach (to not list permitted values in the SYNTAX clause)
> correct? Is this approach acceptable? Should I expect some manager
> complains with that?
>
> Another question regarding a similar thing. I read enumeration values
> should start from value 1 and increase without holes, but I read many MIB
> that didn't adhere to this rule. What do you think?
>
I think you have 3 choices: enumerations, integers the way you are
suggesting, and a simple integer.
Enumerations:
volumeControl OBJECT-TYPE
SYNTAX INTEGER {
mute (1),
level-5 (2),
level-10 (3),
level-15 (4),
...
level-1000 (201)
}
Integers:
But why use enumerations at all when it comes to having so many choices?
Just leave it as a plain integer between 0 and 1000 (where zero is
'off'/'mute')
You might ask about the 'step by 5' issue? I would simply put it into the
definition
that only multiples of 5 are allowed, and then optionally code the agent so
that
if an intermediate value was actually 'set', that it would be rounded
up/down
to a legal value.
Simple Integer:
Why not just have SYNTAX INTEGER (0..100)?
Why the complicated 0 to 1000 with steps of 5? and a special 'mute'
indicator?
Personally... I'd go with INTEGER (0..100).
Fulko
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
