1. to be informed of any problems within the printer from the time the job
is submitted, until the job has completed. If the problem occurs
before the job starts, the user most likely would like to be informed
so he could take action to correct the problem. If he doesn't care, he
most likely does not want any job monitoring information or can simply
filter this information locally.
2. when his job has started.
3. progress of his job while printing.
4. when his job has completed.
By filtering locally, the user application does not have to worry about
finding the correct "edition" and the SENSE "publisher" only has to create
one "edition" for the job.
I cannot see where this configuration is more complex or less ideal than
performing the filtering on the SENSE server. Other than some additional
network traffic, which should be minor, I cannot think of any other
disadvantages.
Adding filters to the SENSE server for the few cases where the user does
not want the "complete package" does not appear to justify the added
complexity for the "publisher". My guess is that in most cases where a
user does not want to know everything, he will ask for everthing and just
ignore what he doesn't care about.
Ron Bergman
Dataproducts Corp.
On Fri, 21 Nov 1997, Jay Martin wrote:
> First, does anyone else on the Sense DL have any comments on this
> topic?
>
> I don't want this thread to degenerate down to just Tom Hastings
> and myself. Longstanding PWG participants know that Tom and I are
> always at the opposite ends of the spectrum in defining things
> (whatever the topic is), and I feel this discussion is going nowhere
> fast without others' opinions.
>
> Tom, regarding some of your statements:
>
> > What we keep trying to tell you is not to be afraid of simple filters.
> > I agree with you that filters can get out of hand. But for IPP
> > for end-users monitoring their jobs and/or the printers to which they
> > have sent jobs, the filter mechanism is just four bits.
>
> If Sense is only for IPP--and it damn well better NOT be--then sure,
> anyone can whip up some simple solution and get it out the door
> tomorrow.
>
> But Sense started off as a means to handle a *wide* variety of
> events, with particular attention to the needs of network printers.
> But not ONLY printers, since other system-related events would
> also be desired (such as Job events, Queue events, etc.)
>
>
> > I repeat the simple IPP requirements (which seem to keep getting deleted):
> >
> > Allow the subscriber to specify a simple subset of the 6 defined IPP
> > event groups (actually only 4, because 'all' and 'none' are really NOT
> > separate events).
>
> Ok, let's take a look at the set of "event classes" as currently
> defined in IPP:
>
> > Standard values are:
> >
> > 'none': the Printer SHALL not notify.
> >
> > 'all': the Printer SHALL notify when any of the events occur.
> >
> > 'job-completion': the Printer SHALL notify when the job containing this
> > value completes (i.e., enters the 'completed', 'canceled', or 'aborted'
> > state) with or without errors.
> >
> > 'job-problems': the Printer SHALL notify when this job has a problem
> > (i.e., when the job leaves the 'processing' state and enters the
> > 'processing-stopped' state).
> >
> > 'job-started-processing': the Printer SHALL notify when the Printer starts
> > processing the Job (i.e., when the job leaves the 'pending' state and
> > enters the 'processing' state).
> >
> > 'printer-problems': the Printer SHALL notify when this job is affected by a
> > Printer problem. This happens when the printer enters the 'stopped' state
> > while this job is in the 'pending', 'pending-held', 'processing', or
> > 'processing-stopped' state.
>
> Tom, here's where you and I *always* tend to disagree. You stated
> previously (in a prior posting) that a user demands *infinite*
> flexibility in selecting which event classes to monitor.
>
> I ask you: in REALITY, how many combinations are really viable here?
>
> Here are some highly suspicious selections, ones that I don't
> think are desired by anyone:
>
> a) Only "job-started-processing" events. (Yeah, sure.)
>
> b) Only "printer-problems" events. Why you would be using IPP
> to monitor printer problems is beyond me. Sure, it can be done,
> but DON'T FORGET THAT THIS FACILITY IS ASSOCIATED WITH AN
> EXISTING JOB, and not some general-purpose printer-specific
> problem reporting mechanism.
>
> I'll stop right there. You see, when you talk about IPP events,
> they are defined in terms of EXISTING jobs, and not some generic
> "IPP printer" environment. By definition (and I think you forget
> this), IPP only gives you events after you've registered for them
> as part of a job submission. Am I wrong here?
>
> I'm going to bet that there are only two combinations of event
> classes that user's will consistently use:
>
> a) Give me all events, I'm a control freak
>
> b) Give me all events EXCEPT job-started-processing, since
> I'm not interested in intermediate events, only final
> events
>
> Sure, some could argue for a couple more combinations. But that's
> just it--only a couple more. Not 14 more to provide all possible
> combinations.
>
> Proposing that a N-way set of combinations is required is
> ridiculous, IMHO, and makes me think you haven't really given
> much thought about real world scenarios.
>
> I'd really like to see some comments from others--either PRO or
> CON--before continuing this discussion.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>