IPP> NOT - Issue 1 - Add Subscription object? [ISSUE: reject/ ignore an already associated subscription?]

IPP> NOT - Issue 1 - Add Subscription object? [ISSUE: reject/ ignore an already associated subscription?]

IPP> NOT - Issue 1 - Add Subscription object? [ISSUE: reject/ ignore an already associated subscription?]

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Aug 6 16:24:17 EDT 1999


Hugo,

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 at novell.com]
> Sent: Friday, August 06, 1999 11:01 AM
> To: hastings at cp10.es.xerox.com; harryl at us.ibm.com
> Cc: mike at easysw.com; ipp at 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 at 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 at us.ibm.com [mailto:harryl at us.ibm.com] 
> Sent: Wednesday, August 04, 1999 07:41
> To: Hastings, Tom N
> Cc: Michael Sweet; Hugo Parra; ipp at 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 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."




More information about the Ipp mailing list