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. T=
his 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 map=
ping
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 convince=
d there
is a practical use for this. Could someone offer a high level diagram o=
f a
practical system where the client is getting job progress information f=
rom 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 o=
n
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 jmJobSubmissionI=
d
for job monitoring. It is clearly undesirable for something downstream=
,
such as NDPS, to then stomp on the jmJobSubmissionId created by the dri=
ver.
Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se=
ems
to be a more straight forward solution. I know the consensus was to no=
t
re-open this, but maybe others are having second thoughts. Can someone=
refresh my memory on the negatives of allowing multiple jmJobSubmission=
Ids?
Stuart Rowley
Kyocera Electronics, Inc.
=