Tom,
> 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.
As I have stated many times, I am very much against the specification
and implementation of event filter specifications in Sense, due to
the fact that such filter specifications typically turn into a full-
blown language...with all the attendant nightmares that go with it.
We tried to strike a balance between simplicity and flexibility in
providing sets of events via the concept of "Editions". The producer
(ie, Publisher) defines event sets and publishes Editions to represent
those event sets. The client then subscribes to the event sets of
interest; when an event arrives for a given subscribed Edition, the
client decides whether the event is "of interest" (ie, filters the
event) and handles it accordingly.
I am very much against the notion of having the protocol/system design
provide Nth-degree filtering. While such filtering can definitely
improve network performance, it comes at a considerable system design
and implementation cost.
We explicitly took the path of "reasonable compromise" in that event
sets are segregated (using Editions), but the client performs local
filtering as desired by the user.
...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 --
----------------------------------------------------------------------
--------------CD7E0C95A648CCB8D73548E9
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by uscore.underscore.com (8.8.4/8.7.2) with SMTP id RAA10158 for <jkm@underscore.com>; Tue, 18 Nov 1997 17:11:20 -0500 (EST)
Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <56847(1)>; Tue, 18 Nov 1997 11:22:48 PST
Received: from garfield.cp10.es.xerox.com by norman.cp10.es.xerox.com (4.1/SMI-4.1)
id AA23312; Tue, 18 Nov 97 11:03:18 PST
Received: from dellxpi-11 (dellxpi-11 [13.240.120.138])
by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id LAA03949;
Tue, 18 Nov 1997 11:00:05 -0800 (PST)
Message-Id: <3.0.1.32.19971118110828.00f5d630@garfield>
X-Sender: hastings@garfield
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 18 Nov 1997 11:08:28 PST
To: Jay Martin <jkm@underscore.com>
From: Tom Hastings <hastings@cp10.es.xerox.com>
Subject: Re: SENSE> SENSE Req review
Cc: Harry Lewis <harryl@us.ibm.com>, sense@pwg.org
In-Reply-To: <346E1BD4.86C1D8E7@underscore.com>
References: <5030300013707863000002L032*@MHS>
<3.0.1.32.19971114121136.0107fb10@garfield>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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...
--------------CD7E0C95A648CCB8D73548E9--