Web Based Monitoring and Management: WBMM> PWG Counter MIB -

WBMM> PWG Counter MIB - 3 model choices

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sun Feb 29 2004 - 16:03:15 EST

  • Next message: McDonald, Ira: "WBMM> FW: [Printing-architecture] Bi-di Plug-in API draft document"

    Hi, Sunday (29 February 2004 - 'leap day')

    Here are three alternatives for structuring a PWG Counter MIB:

    (1) Object-Oriented Model
        - see my recent PWG Imaging System MIB proposal
        - delete Attribute table (no configuration for services/devices)
        - define Counter table w/ dictionary counter enums, e.g.,

        IcCounterTypeTC ::= TEXTUAL-CONVENTION
        ...
        SYNTAX INTEGER {
            other(1), -- non-standard counter
            unknown(2), -- unknown counter type

            -- impression counters
            totalImpressions(51), -- INTEGER - Counter32
                -- total impressions printed by this system/service/device
            blankImpressions(52), -- INTEGER - Counter32
                -- blank impressions printed by this system/service/device
            ...
        }

        - Pros: Most compact definition
                Most similar to Job MIB
                Easily extended (register new enums in separate TCs MIB)
        - Cons: Most complex for implementors

    (2) Hybrid Model
        - see my recent PWG Imaging System MIB proposal
        - delete Attribute table (no configuration for services/devices)
        - define Counter table w/ classic columnar objects (not enums), e.g.

        IcCounterEntry ::= SEQUENCE {
            icCounterParentClassIndex Integer32, -- service/device
            icCounterParentObjectIndex Integer32, -- pointer
            icCounterInputImages Counter32,
            icCounterOutputImages Counter32,
            icCounterImpressions Counter32,
            icCounterBlankImpressions Counter32,
            icCounterBlackImpressions Counter32,
            icCounterFullColorImpressions Counter32,
            icCounterHighlightColorImpressions Counter32,
            ...
        }

        - Pros: Fairly compact definition
        - Cons: Still complex for implementors
                Differs from both Job MIB and Printer MIB models
                All counters must be OPTIONAL (w/ many conformance groups)

    (3) Classic Model
        - see my recent PWG Imaging System MIB proposal
        - delete Attribute table (no configuration for services/devices)
        - define _many_ counter tables w/ classic columnar objects, e.g.

        IcCopyCounterEntry ::= SEQUENCE {
            icCopyServiceIndex Integer32, -- pointer
            icCopyDeviceIndex Integer32, -- pointer
            icCopyInputJobs Counter32,
            icCopyInputImages Counter32,
            icCopyImpressions Counter32,
            icCopyBlankImpressions Counter32,
            icCopyBlackImpressions Counter32,
            icCopyFullColorImpressions Counter32,
            ...
        }

        IcPrintCounterEntry ::= SEQUENCE {
            icPrintServiceIndex Integer32, -- pointer
            icPrintDeviceIndex Integer32, -- pointer
            icPrintInputJobs Counter32,
            icPrintInputKOctets Counter32,
            icPrintImpressions Counter32,
            icPrintBlankImpressions Counter32,
            icPrintBlackImpressions Counter32,
            icPrintFullColorImpressions Counter32,
            icPrintHighlightColorImpressions Counter32,
            ...
        }

        - Pros: Least complex for implementors
                Most similar to Printer MIB
        - Cons: Very high redundancy
                Very large MIB (w/ many conformance groups)
                Requires revised MIB for a new service (not just enums)

    Comments?

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    This archive was generated by hypermail 2b29 : Sun Feb 29 2004 - 16:03:25 EST