Yes, I think both the NDPS client app and a DocWise-like application could
be trying to provide job monitoring information to the user. Why would a
user want both? They probably wouldn't, but they may prefer the monitoring
provided by NDPS over that provided by the DocWise-like app. However, in
our scenario, the NDPS supplied jmJobSubmissionId would have been
overridden by the driver supplied jmJobSubmissionID. I don't think this
scenario is far-fetched.
In this example there are essentially two in-band monitoring apps.
DocWise-like apps would exist for product differentiation or to provide job
monitoring in environments which would not otherwise provide it. NDPS or
other similar component would provide job monitoring because a DocWise-like
app may not be in use. We now have a mib design where these apps will
collide unless they use some complicated method to avoid it. If they
collide, then the user's choices for a preferred job monitoring method
would have been limited. This doesn't seem like a good thing.
Stuart Rowley
Kyocera Electronics, Inc.
______________________________ Reply Separator _________________________________
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Author: INTERNET:harryl@us.ibm.com at CSERVE
Date: 11/18/97 10:52 AM
Stuart, are you suggesting that, in an NDPS environment (for example), BOTH a
"driver spawned" job monitoring client application (like DocWise) AND a NOS
provided monitoring paradigm (NDPS) will be in operation at the same time on
the same job? Why would the end-user want 2 ways to monitor the print job?
Part of the decision to use "last encountered" jmJobSubmissionID was to keep
the agent simple, yes, but this decision was also based on the premise that
only one "tightly coupled" monitoring application need be in control. This is
not to say "out of band" applications can't still monitor - just not in the
"pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping
table.
I don't strongly object to moving to a design where multiple
jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there
is a practical use for this. Could someone offer a high level diagram of a
practical system where the client is getting job progress information from two
sources, simultaneously?
Harry Lewis - IBM Printing Systems
jmp-owner@pwg.org on 11/17/97 06:15:16 PM
Please respond to jmp-owner@pwg.org @ internet
To: JMP@pwg.org @ internet, rbergma@dpc.com @ internet
cc:
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Ron,
I am increasingly uncomfortable with the agreement to use the last
submission id encountered. I believe the original decision was based on
the idea that it was the simplest solution, but your write-up on the
Proposed Rules for jmJobSubmissionId shows that this solution is not so
simple or straight forward after all.
I can see the possibility of an application that works closely with the
driver, such as HP's DocWise, using the driver created jmJobSubmissionId
for job monitoring. It is clearly undesirable for something downstream,
such as NDPS, to then stomp on the jmJobSubmissionId created by the driver.
Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems
to be a more straight forward solution. I know the consensus was to not
re-open this, but maybe others are having second thoughts. Can someone
refresh my memory on the negatives of allowing multiple jmJobSubmissionIds?
Stuart Rowley
Kyocera Electronics, Inc.