>>> "Hastings, Tom N" <hastings@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. =20
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 =20
=20
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=20
back on IPP's having a "job-uri" to specify the target of a Job operation,=
=20
so lets not repeat that for the Subscription object.
2. Presumably the authorization and authentication for creating Subscriptio=
n
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. =20
Until such an association is made between a Subscription object and =
either:
(1) a Printer object (in which the Subscription object is contained) =
or=20
(2) a Job object,=20
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. =
=20
<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.=20
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@easysw.com]=20
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:
>=20
> Here are the issues in the posted notifications spec. Lets start
> the discussion of them on the DL:
>=20
> 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=20
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=20
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@easysw.com=20
Printing Software for UNIX http://www.easysw.com=20
"Your logic is impeccable, Captain. We are in grave danger."