I've inserted some comments below.
>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 07/27/99 02:05PM >>>
Michael,
A number of us at Xerox discussed your proposal and we like it a lot. It
reduces the total number of operations and is more object-oriented, while
still maintaining the simplicity of the Job Submission Subscription
mechanism.
Comparing the approaches for the Explicit Subscription operations:
Current spec Your proposal
------------ -------------
Subscribe-Job Create-Subscription
Subscribe-Printer
Renew-Printer-Subscription Renew-Subscription
Unsubscribe-Printer Cancel-Subscription
Unsubscribe-Job
Get-Job-Attributes - Job Sub. Get-Subscription-Attributes
no way to get Printer Sub.
Get-Printer-Subscriptions Get-Subscriptions
Get-Job-Subscriptions
However, we have the following suggestions:
1. Instead of using a URI to specify the target of a Subscription operation,
we suggest that a Subscription object be specified using a Printer URI and a
subscription-id (32-bit integer), just like jobs. There as been a lot of
push
back on IPP's having a "job-uri" to specify the target of a Job operation,
so lets not repeat that for the Subscription object.
2. Presumably the authorization and authentication for creating Subscription
objects would be handled by the implementation the same as jobs, whatever
that is.
3. The client would supply as part of a Create-Subscription operation would
be one of the following:
a. The Printer-URI to associate this Subscription with (has to be the
same Printer-URI as the target of the Create-Subscription operation
b. The job-id (rather than the job-uri) of the (previously created) Job
to associate this Subscription with.
c. Neither - the Subscription will be associated in a subsequent create
job operation (Create-Job, Print-Job, Print-URI, Validate-Job).
<HParra> I think (a) works well. (b) has the problem that it's done after the job has been created and runs the risk of missing relevant events. (c) presents the following challenges: there's no way to tell the printer what job to associate the subscription with since no job-id has been generated. How does the printer differentiate this subscription from an (a) subscription so that it doesn't start generating events until a job-to-subscription association is made? Also, what happens if the same suscription id is used with more than one subsequent job creations. How do we clean up subscriptions that are never associated with a job? What happens if a subscription is removed before the job completes? Does the subscription go away automatically when the job is removed? I think it should. Keeping subscriptions and job objects in sync can be pretty involved.
Until such an association is made between a Subscription object and either:
(1) a Printer object (in which the Subscription object is contained) or
(2) a Job object,
the Subscription object doesn't produce any event notifications. This is
because until the association is made, it isn't clear whether a Job event
means all jobs or just the job that the subscription is associated with.
<HParra> There has to be a way for end-users to request notification of events that are related or directly affect their jobs and nothing else.
4. A create job operation (Create-Job, Print-Job, Print-URI) perform the
association implicitly between the job being created and the Subscription
being passes as create job operation attributes. Presumably, an additional
operation attribute in the create job can associated a previously created
Subscription object with the Job being created.
Comments?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, July 27, 1999 05:43
To: Hastings, Tom N
Cc: ipp
Subject: Re: IPP> NOT - 27 ISSUES in Updated IPP Event Notifications
spec posted, 7/22/99
[Sorry - first chance I've had to look at the notification stuff in
detail!]
"Hastings, Tom N" wrote:
>> Here are the issues in the posted notifications spec. Lets start
> the discussion of them on the DL:
>> ISSUE 1: Do we need to add a Subscription object that contains the
> "notify-recipients", "notify-events", "subscription-id", and
> "lease-time" attributes (and possibly the opaque subscription
> attribute, if we add it)?
I think we do need subscription objects, but not necessarily as part
of jobs & printers. Looking through the notification stuff it looks
like the current plan is to place "warts" (sorry, I can't think of
a better word for it...) on printer and job objects to support
notification, which will probably make implementation a pain - two
separate places for the notification software to look for
subscriptions, for example.
I would suggest the following alternative:
1. Create a "subscription" object that contains all of the
needed attributes, including printer-uri or job-uri that
associates the subscription with a particular printer or
job URI.
2. Add the following new operations:
create-subscription
cancel-subscription
renew-subscription
get-subscription-attributes
get-subscriptions
3. Support automatic subscription for the create-job, print-job,
or print-uri operations using the current scheme.
4. Add the supported notification attributes and operations to the
get-printer-attributes operation.
The rest of the spec would then apply to the new subscription object
and how #1-4 tie everything together.
snip...
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com
"Your logic is impeccable, Captain. We are in grave danger."