> However, we all agree that this simple filtering is a good add to
> SENSE, so we can leave it at that.
And I agree with you. No problem there.
I'd like to go into a bit of detail about this part of your posting:
> As an example, my default printer currently has 51 jobs in the queue,
> because something is wrong with the printer. Sending out 51 notifications
> to all users who are in the queue whenever the printer has (more) problems
> will add to the network traffic.
First off, 51 notifications will only be sent if 51 clients have
subscribed to events for the printer; if a client does not subscribe
to the relevant Edition of the printer, then it will not receive any
events (by definition).
Perhaps where we might be getting lost here is in the implementation
of a "print job" in the Sense model. If a printer published an
Edition for each outstanding job--and every client subscribed to
ALL job Editions, then yes, the client would get 51 (similar) events
upon the occurance of a job-affecting printer event, one for each
job Edition the client subscribed to.
It's important to note that we have not really defined how a
job--in particular, an IPP job--would be modeled and implemented
in the Sense domain. We have often touched on the notion of a
model where "one Edition = one job", so let's explore that for
a moment.
Imagine a client application designed as a "personal job monitor"
that continually monitors a defined list of printers, looking
for Editions that represent jobs associated with the app's user.
Let's call such an Edition a "Job Edition" here.
Whenever a Job Edition is found that appears to be related to
the user, the app subscribes to the Edition. The Edition may
be implemented to support multiple event classes (via the new
"Event.Classes" property in the Edition); if so, then the app
might also specify one or more filters when subscribing to the
Edition. Otherwise, the app will receive all events upon
subscribing to the Edition.
Then, when the printer encounters a problem of some sort,
either within itself (ie, a device fault) or within the
job (ie, job fault), then the client would get exactly one
event message, assuming the event has not been filtered.
This will be true whether there is 1 job in the queue, or
51 jobs, or whatever number of jobs.
If, on the other hand, a client subscribes to *all* Job Editions,
then the client would get 51 events (one for each Edition) when
a printer problem event occurs.
Tom, does this jive with your thinking?
...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 --
----------------------------------------------------------------------
Tom Hastings wrote:
>
> Ron and I have a disagreement here.
>
> I believe that having every client host get a notification message
> if it has a job pending for a printer whenever that printer gets a
> problem, cause a network problem when the queue gets long. Sure
> such client can filter out the notifications and not both the user
> who doesn't want them. But the simple filtering you propose
> eliminates the need for the client to filter out the notification.
>
> As an example, my default printer currently has 51 jobs in the queue,
> because something is wrong with the printer. Sending out 51 notifications
> to all users who are in the queue whenever the printer has (more) problems
> will add to the network traffic.
>
> Also clients don't need to filter out job start processing notifiation
> when the user's job starts processing for those users that don't want
> to be bothered with that notification.
>
> So this mechanism makes it simpler for clients. They don't need to filter
> at all.
>
> However, we all agree that this simple filtering is a good add to
> SENSE, so we can leave it at that.
>
> Tom
>
> At 08:33 12/08/1997 PST, Ron Bergman wrote:
> >
> >
> >---------- Forwarded message ----------
> >Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST)
> >From: Ron Bergman <rbergma@dpc.com>
> >To: Jay Martin <jkm@underscore.com>
> >Subject: Re: SENSE> New proposal for Server-based event filtering
> >
> >Jay,
> >
> >(Sorry so late for this reply. Im in Washington state and they changed
> >the remote phone number and I could not get the new one until today.)
> >
> >Your proposal seems like a good addition to sense, but I am not convinced
> >that it is really needed for IPP. I still do not believe that the
> >combinations proposed by Tom will really be needed.
> >
> >But I also believe that there may be other situations (other than IPP)
> >where the filtering may be useful.
> >
> > Ron
> >
> >
> >
> >
> >