I had a task to write up a new use case and flow diagram. I got hung up as
you can see below and need some explanation about the two ways for a
client to associate a target device with a job and specify the document
type transform.
1. Job is submitted to a printer via IPP or some other “legacy”
protocol
a. Job is in some document format the printer does not
support natively
b. Printer will behave as both client and target device to
engage print (transform) service.
c. Printer does not want to poll to know when the print
service has completed the transform and is ready to deliver the job
2. Using the TargetDeviceSupported Interface on the print service,
Printer registers with print service as Target Device
a. targetDeviceSupportInterface
i. registerTargetDevice
ii. deliveryMethod – “push”
3. Using the JobControl Interface on the print service, Printer
(acting as client) defines targetDevice, specifies “deliver” and requests
a data type to translate to (of course the Printer will request the
correct document format for itself… the whole point of this exercise).
a. jobControlInterface
i. createJob
1. targetDeviceIdentifier
2. deliverToTargetDevice = true
3. requestedTargetDeviceDataType
OK HERE’S (ONE PLACE) WHERE I’M LOST
4. Using the targetDeviceSupportedInterface on the print service,
Printer COULD associate the target device with the UID acquired during
createJob (right?) and also request the target device data type
a. targetDeviceSupportInterface
i. associateTargetDevice
1. jobURI
2. userID
3. targetDeviceIdentifier
4. requestedTargetDeviceDataType
What am I missing? Why do I feel like (3) and (4) are mostly redundant? Is
one supposed to represent a longer term relationship between client and
print service while the other should be thought of more as a “per job”
specification?
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
This archive was generated by hypermail 2b29 : Tue Oct 08 2002 - 02:03:33 EDT