At 14:01 11/15/1997 PST, Jay Martin wrote:
>Tom Hastings wrote:
>snip...
>In other words, I believe Sense is already designed to handle what
>you'd like to see, and if there are any holes remaining, we can
>certainly fill them using the kind of approach you and Harry have
>suggested. No issue here.
>>>> A value of 1 would mean unrealiable.
>>Actually, I'd suggest a value of 0 to indicate "no retries" (ie, a
>retry count of zero). Seems to be more elegant and useful, no?
I agree. Its a retry count, so 0 means no retries.
snip...
>As you mention, the prior established specifications for IPP job-
>related events reception by a client are:
>> none
> all
> job-completion
> job-problems
> job-started-processing
> printer-problems
>>Of course, in the case of Sense, the "none" case is not relevant;
>the Subscriber client simply does not subscribe to any of the
>associated Editions.
>>Separate Editions can be designed for the remaining types, though.
>To keep life simple, it would be best for us to focus on the "all"
>case, since I honestly believe this specification will be used by
>most clients. (Agreed?)
>>What we need to do then is:
>> 1) Name the Edition. Something like "IPP.Job.AllEvents" would
> follow what we have done in the Printer MIB area, but this
> choice is obviously quite arbitrary. What can be important,
> though, is the left-to-right dotted-string convention for
> naming things in a rough hierarchical manner.
While "all" might be the most used, it depends on the operator coverage
of the printer and whether the user likes lots of notifications or not.
For printers that have operator coverage, only getting "job-completion"
would be most used.
I also found the "job-started-processing" event annoying, though some
like it a lot. It depends on whether the print system responds in the
create job response with whether the job was started or is pending.
If the print system does (and VMS did), and for printers that are often
idle (10% duty cycle), just knowing that the printer was idle when the
job was submitted is better than being notified asynchronously (usually
almost immediately) that the job has just started.
In other words, I belive that which of the above combinations of events
is very much a user preference issue. Does SENSE have any problems
with allowing users to choose any combination? Does allowing users to
choose mean that there has to be combinations of editions for each
combination, each with a different name? Is this a problem to have
to have so many combinations?
If yes, then I'd like to see if we can fix SENSE architecture
so that the SENSE server does a minimal amount of filtering as stored
with the subscription. The publication lists what are the (short) list
of event groups and the subscription says which event groups are wanted.
The SENSE server ignores sending notifications to subscribers that
do not have the indicated event group in their subscription.
Would this be feasible?
Tom
snip...