Hi Ron,
A thought, because I was just doing the edits in Counter MIB.
The Counter MIB itself has a table of all the Services (FaxOut,
Scan, Print, etc) and all the Subunits (including Scanner).
By adding just ONE columnar object from the older Imaging
System MIB to the Service table, we could have the pointer
list (as a bit-mask of indices) to the Subunits from each
Service. By using the same indices for the Subunits in
Counter MIB as in the Printer MIB, the problem of multiple
affected Services for an Alert would be neatly solved.
Several printer vendors have expressed interest in prototyping
Counter MIB, because it's the quickest path to multifunction
counters (without web services), so we might talk about this.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of
Ron.Bergman at ricoh-usa.com
Sent: Wednesday, February 28, 2007 4:35 PM
To: pmp at pwg.org
Subject: PMP> MFP Alerts Meeting Minutes, February 19, 2007; Maui
The slides outlining the points for discussion can be found at:
ftp://ftp.pwg.org/pub/pwg/pmp/presentations/MFPAlertsMeeting-20070219.pdf
The primary topic of discussion was in regard to subunits that are used by
more than one service. (Example, paper input trays may be used by the
print, copy, and fax-in services.) The question poised was "how can an
application determine which services are affected?" After a short
discussion, it was agreed that the proposed alert table index groupings in
Appendix A could not properly provide this information in all cases. A
better method would be to define a new service status mechanism as a new
working group project. It was also agreed to add a short note to Appendix
A explaining this decision and to indicate this method was not recommended
for use by the working group.
I have drafted the following text to be inserted at the beginning of
Appendix A. If there are no comments received, I will issue the revised
document next week.
Working Group analysis and cautions regarding this method.
The following proposal was discussed extensively within the working group
and several scenarios were presented that could not be resolved in a
reasonable manner using the described method. The basic issue relates to
the fact that the alert table is hardware centric and not service oriented.
To adequately present the effect of an alert condition on all services
would, in many cases, require multiple entries in the table for a single
alert condition. The working group agreed that this is not a desired
approach and will investigate alternate approaches to provide service
status information as a follow-on project. The alert table information
should be used only to obtain hardware status.
The original text of the proposal follows. NOT RECOMMENDED…
Ron Bergman
Chairman, Printer MIBs Working Group
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.5/707 - Release Date: 3/1/2007
2:43 PM