On Fri, Mar 5, 2010 at 8:58 AM, Dave Shield <[email protected]>wrote:
> On 5 March 2010 13:42, Fulko Hew <[email protected]> wrote:
> > The closest merge to your original request would be the following
> >
> >
> > abc OBJECT IDENTIFIER ::= { application 1 }
> > xyz OBJECT IDENTIFIER ::= { application 2 }
> >
> > noOfMessages OBJECT-TYPE
> > SYNTAX INTEGER
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION "Number of Messages Transfred." "
> > ::= { abc 1 }
> >
> > noOfMessages2 OBJECT-TYPE
> > SYNTAX INTEGER
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION "Number of Messages Transfred." "
> > ::= { abc 2 }
> >
> > Here you end up with two variables each at unique leafs:
>
> I'd suggest that a better merge would be to keep the second
> object as a child of 'xyz' rather than 'abc'. Since it's presumably
> counting the number of XYZ messages transferred.
>
Depends on what the original usage was, and we don't know.
(Did the two variables actually count the 'same' thing,
but was simply being exposed in two different leafs???)
> I'd also suggest using the group name as a prefix to the
> object name. This is the normal convention for MIB
> management objects, and means that the distinction
> between 'abcNoOfMessages' and 'xyzNoOfMessages'
> is reasonably clear from the names.
>
> Calling them 'noOfMessages' and 'noOfMessages2' is
> nigh on meaningless!
>
Good points Dave. I was simply trying to disambiguate.
I (inappropriately) avoided style/naming conventions.
So depending on the original usage, the two choices could be:
abcNoOfMessages / xyzNoOfMessages <-- counting two different things
versus
noOfMessages / noOfMessagesCopy <-- same count shown in two different
places
noOfMessagesFromAbc / noOfMessagesFromXyz
(I think Prakash can use all these suggestions to
determine whats most appropriate for his situation.)
Fulko
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
