IPP Mail Archive: IPP> Simplifying suggestion for notification

IPP> Simplifying suggestion for notification

Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Mon, 28 Jun 1999 19:03:56 -0700

We have been struggling with the event subscription mechanism for many
months now. One particularly difficult requirement has been to allow
clients to submit a job containing a subscription to events for two or more
separate targets, each subscribing to a different set of events.

An early proposal required that we introduce a "Collection" data structure
to meet this requirement. The Collection solution seemed too complex for
many. More recently, to avoid this complexity, we have tried eliminating
this requirement and proposed that the events related to the job be the same
for all recipients, but some people believe this to be too restrictive and
that we should meet the original requirement.

We have also had proposals for a "subscribe" operation, which allows a
client to subscribe to a set of events on a printer. But this operation
doesn't allow a person to subscribe to events for a particular job.

I have an alternate suggestion. Let's add another operation called
"subscribeJob" which allows a user to subscribe to events for a particular
job. Let's rename "subscribe" to "subscribePrinter". The operation
attributes for subscribeJob, subscribePrinter and CreateJob would include
the same two parameters, the set of events applies to each of the members of
the set of recipient targets. CreateJob contains additional operation
attributes; the other two don't.

This solution eliminates the need for supporting different events for
different targets in the same operation.
If a client wants different events for different targets, one set goes with
the createJob and the other with a subscribeJob operation. An
implementation that doesn't support subscribeJob probably wouldn't support
different targets with different events on a CreateJob operation either.

The only downside that I see is that in some cases the job may have
completed before the subscribe operation arrives, in which case the
subscription fails. So for example, if the user wants to receive an event
for both page completion and job completion and he wants his secretary to
receive only job completion, the best strategy is to submit the job with a
request for the job completion event with targets of the secretary and the
user, and then to subscribe to page completion separately.
To avoid a potential race condition, the job could be held until after the
subscriptions have completed if a printer supports hold/release.

Bob Herriot