The "per-printer" / "my jobs" subscription is difficult to implement (e.g., does the subscription affect future job submissions?) and the same functionality can be accomplished as a "per-job" subscription. Is this raising the bar too high for implementors of IPP Notification?
-Hugo
.
>>> <harryl at us.ibm.com> 08/04/99 08:41AM >>>
Regarding this comment
>As for the case where the user sends another job that is associated
>with an already assigned subscription, I don't think we've discussed
>this possibility yet. My personal feeling is that reusing the
>subscription ID should probably not be allowed, but we could also
>treat it as a special renew operation that also changes the
>subscription.
I see it differently. There are two types of subscription... "perJOB" or
"perPRINTER".
"PerPrinter" should be able to accommodate "myJobs" or "allJobs" (with filters
for specific criteria in either case).
Typically, a "perJOB" subscription would be expected as part of that Job
submission
Typically, a "perPRINTER" subscription would be expected via an "out of band"
method but could occur in job submission
The only scenario where the user sends another job associated with an already
assigned subscription should be with
a "perPRINTER" subscription.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 08/04/99 01:20:14 AM
To: Michael Sweet <mike at easysw.com>, Hugo Parra <HPARRA at novell.com>
cc: ipp at pwg.org
Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE: reject/
ignore an already associated subscription?]
Hugo,
Michael did a good job answering your questions. Sound ok?
He had one issue:
Each subscription will be associated with a single printer or job
object. There has been discussion of "subscription sets" that would
allow a subscription to be associated with more than one object
and/or set of conditions, but my feeling is that most people don't
want to add this complexity, especially since the client is free to
create additional subscriptions that do the same thing.
As for the case where the user sends another job that is associated
with an already assigned subscription, I don't think we've discussed
this possibility yet. My personal feeling is that reusing the
subscription ID should probably not be allowed, but we could also
treat it as a special renew operation that also changes the
subscription.
TH> I agree with his feeling that a subscription can only be associated with
one Printer object or one Job object. That is what I put in the
Notifications Model document that I send out Monday. Subscription objects
are so big that there is any real savings to being able to have one shared
between multiple jobs or between a Printer and a Job.
So if a Job Creation operation specifies a Subscription object that is
already associated with another Job or the Printer, the Job Creation
operation doesn't allow it.
ISSUE: Return an error which prevents the Job Creation, or accept the Job
Creation anyway, but since the Job Creation returns the subscription ids
that have been assigned, this erroneous one won't be in the list.
Ok?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Friday, July 30, 1999 05:29
To: Hugo Parra
Cc: hastings at cp10.es.xerox.com; ipp at pwg.org
Subject: Re: IPP> NOT - Issue 1 - Add Subscription object?
Hugo Parra wrote:
> ...
> <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
That's why a user can request notifications when the create-job,
print-job, or print-uri operation is done.
> 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
Sigh... The create-job, print-job, and print-uri operations will
have added operation attributes to address this, either by specifying
a subscription ID or the notification attributes to create a new
subscription automatically.
> 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
Each subscription will be associated with a single printer or job
object. There has been discussion of "subscription sets" that would
allow a subscription to be associated with more than one object
and/or set of conditions, but my feeling is that most people don't
want to add this complexity, especially since the client is free to
create additional subscriptions that do the same thing.
As for the case where the user sends another job that is associated
with an already assigned subscription, I don't think we've discussed
this possibility yet. My personal feeling is that reusing the
subscription ID should probably not be allowed, but we could also
treat it as a special renew operation that also changes the
subscription.
> we clean up subscriptions that are never associated with a job?
First, subscriptions have a "lease" time, which means that after a
certain amount of time the subscriptions are automatically expired
(cancelled.) Once a subscription is tied to a job, however, the
subscription will remain alive until the job is cancelled or
completed.
> What happens if a subscription is removed before the job
When the subscription is cancelled the user no longer gets
notifications.
> completes? Does the subscription go away automatically when the
As noted above, subscriptions that are tied to a job are cancelled
when the job is completed or cancelled.
> job is removed? I think it should. Keeping subscriptions and
> job objects in sync can be pretty involved.
> ...
We've already done some preliminary design work to work notifications
and subscriptions into CUPS 1.1, and the code to manage such things
is not all that complicated.
> <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.
Then they just subscribe when they send the job, so the subscription
applies to the job. Or they can do a create-subscription operation
and supply the subscription-id attribute with the job creation
operation.
--
______________________________________________________________________
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."