You are right that there are other ways to achieve the same effect, e.g. by
having a profile in your IPP client that always asks for the same kind of
subscription for all jobs that you submit. If we think that this is too
complicated for a printer or print server to keep track of, then we can
describe how it could be achieved from the client instead.
Carl-Uno
> -----Original Message-----
> From: Hugo Parra [mailto:HPARRA@novell.com]
> Sent: Friday, August 06, 1999 11:01 AM
> To: hastings@cp10.es.xerox.com; harryl@us.ibm.com
> Cc: mike@easysw.com; ipp@pwg.org
> Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE:
> reject/ignore an already associated subscription?]
>
>
> I wonder how likely we are to run into the scenario Tom
> described (below). It is printer operators who are more
> likely to have rights to add and manage "per-printer"
> subscriptions. How will end-users get the subscription's id
> to send with their jobs if they are restricted to not deal
> with"per printer" registrations?
>
> -Hugo
>
> >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 08/04/99
> 10:41AM >>>
> Harry wrote:
>
> The only scenario where the user sends another job associated with an
> already
> assigned subscription should be with a "perPRINTER" subscription.
>
> TH> In other words, the following scenario would happen:
>
> 1. Some user creates a Subscription object and associates it with the
> Printer object using Create-Subscription with the
> "associated-printer" set
> to 'true'
> and gets back subscription-id 105.
>
> 2. Later in a job creation operation, such as Print-Job, the (same or
> different) user passes in the "subscription-id" = '105'.
>
> That is how the same Subscription object could be associated
> with both a
> Printer object and a Job object.
>
> BTW, I like your shortened terminology of "per-printer"
> Subscription objects
> and "per-job" Subscription objects, rather that a "Subscription object
> associated with a Printer object" and a "Subscription object
> associated with
> a Job object".
> I think using this terminology will help understanding.
>
>
>
>
> The Problem with Sharing a Subscription object
>
> The problems with allowing a single Subscription object to be both a
> perPrinter (subscription associated with the printer in the
> Create-Subscription operation)
> and a perJob (Subscription associated with a job in either the
> Create-Subscription operation or the job creation operation) are:
>
> 1. There is one subscription ID and one object for the single
> Subscription
> object, so a Cancel-Subscription '105' would get rid of both.
>
> 2. The job events in the subscription object, such as
> 'job-completed' mean
> different things for the perPrinter vs. the perJob. For the
> perPrinter,
> they mean any job and for the perJob, they mean only this job.
>
> 3. There would be access control problems as well. What if I
> had created
> the perPrinter subscription object and you tried to associate
> it with your
> job. Should you be allowed to?
>
>
> Remember that both perPrinter and perJob subscriptions can
> have printer
> and/or job events in them. So I don't see any need for sharing the
> subscription object between the Printer object and one Job
> object. And you
> seem to agree that we don't want to allow sharing of a single
> Subscription
> object between several job objects. Subscription objects are
> so small,
> there is no real gain in sharing them. Sharing always
> complicated things,
> by adding use counts and raising nasty access control issues.
>
> So, ok that a Subscription object either is associated with
> its Printer
> object or with ONE Job object or neither, because it is (and
> possibly others
> Subscription objects are) waiting to be associated with a
> (near) future Job
> object. Ok?
>
> The object relationships can best be summarized in this
> picture that I put
> into the Notification Model document I sent Monday:
>
> The object association relationships can be seen pictorially
> as (object
> containment not shown):
>
> Subscription objects Printer object
> +----+ +------------+
> | s1 |<---------------------------------------------->| |
> +----++ | |
> | s2 |<--------------------------------------------->| p1 |
> +----++ | |
> | s3 |<-------------------------------------------->| |
> +----++ +------------+
> | s4 | Job objects
> +----++ +------+
> | s5 |<---------->| |
> +----++ | j1 |
> | s6 |<--------->| |
> +----++ +------++
> | s7 |<--------->| |
> +----+ | j2 |
> | |
> +------++
> | |
> | j3 |
> | |
> +------+
>
> In words:
>
> 6.1 Object Relationships
>
> When the Subscription object is supported, it is created and
> associated with
> one Printer object, one previously created Job object, or
> neither (so that a
> subsequent job creation operation can perform the association
> of the Job
> object with the Subscription object and possibly other
> previously created
> Subscription objects).
>
> The object relationships can be stated as follows:
>
> The Printer object contains zero or more Subscription objects
> A Subscription object is contained in one Printer object
>
> A Subscription object is exactly one of:
>
> associated with one Printer object (s1-s3)
> associated with one previously created Job object (s5 and s6 are
> associated
> with job j1, s7 is associated with job j2)
> not associated with either a Printer object or a Job object (s4)
>
> A Printer object is associated with zero or more Subscription
> objects (p1 is
> associated with s1-s3)
>
> A Job object is associated with zero or more previously
> created Subscription
> objects:
> j1 is associated with s5 and s6;
> j2 is associated with s7
> j3 is not associated with any s objects
>
> A Subscription object cannot be contained in or associated
> with more than
> one Printer object
> A Subscription object cannot be associated with more than one
> Job object
> A Subscription object cannot be associated with both a
> Printer object and a
> Job object
> A Subscription object MUST be associated ONLY with jobs that
> are contained
> in its Printer object
>
> Tom
>
>
>
> -----Original Message-----
> From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
> Sent: Wednesday, August 04, 1999 07:41
> To: Hastings, Tom N
> Cc: Michael Sweet; Hugo Parra; ipp@pwg.org
> Subject: RE: IPP> NOT - Issue 1 - Add Subscription object? [ISSUE:
> reject/ ignore an already associated subscription?]
>
>
>
>
> 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@us.ibm.com
>
>
> "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 08/04/99 01:20:14 AM
>
> To: Michael Sweet <mike@easysw.com>, Hugo Parra <HPARRA@novell.com>
> cc: ipp@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@easysw.com]
> Sent: Friday, July 30, 1999 05:29
> To: Hugo Parra
> Cc: hastings@cp10.es.xerox.com; ipp@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@easysw.com
> Printing Software for UNIX
http://www.easysw.com
"Your logic is impeccable, Captain. We are in grave danger."