Subject: Re: SENSE> New proposal for Server-based event filtering (fwd)

From: Ron Bergman <[email-masked]>
Date: Mon, 8 Dec 1997 08:33:24 -0800 (Pacific Standard Time)

---------- Forwarded message ----------
Date: Mon, 1 Dec 1997 11:52:57 -0800 (PST)
From: Ron Bergman <[email-masked]>
To: Jay Martin <[email-masked]>
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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Dec 1997 09:19:09 PST

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

---

From: Jay Martin <[email-masked]>
Date: Wed, 10 Dec 1997 15:50:00 -0500

Tom,

> SENSE, so we can leave it at that.

And I agree with you.  No problem there.

> 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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Dec 1997 15:47:47 PST

>to the relevant Edition of the printer, then it will not receive any

So we need to understand when a printer publishes an addition.

Scheme A:
Does a printer publish a separate edition for each job received?
If so, then the name of the edition has to be related to the job id,
so that a client subscribes to the correct edition(s).

By the way, I assume that a management app can't subscribe to an edition that
hasn't been published, so the management app as to wait until the job
is accepted by the IPP printer and the IPP printer has published the
editionn for that job, correct?

Scheme B:
Or does a printer publish a single edition for the printer that generates
job event notifications?
If so, then the name of the edition would be related to the name of the
printer, so that the client could subscribe to the correct edition.

There are pros and cons to each, I'm sure.

>job Edition the client subscribed to.

This is scheme A.

>subscribing to the Edition.

How would the app distinguish between Job Editions that were for jobs
that its user had submitted from Job Editions that were for jobs
that other users had submitted?  Would there be some Job Edition attribute
that indicates the user (name) that submitted the job?  Then the
management app would look at each new Job Edition and see if the user
name matched the one that the app was monitoring for.  Or would the
name of the edition have the user name (or job id) in it?

With scheme A, the monitoring app would have to also subscribe to 
events that create Job Editions, so as not to have to poll the
SENSE server, correct?  So each user client is getting a notification
for any user's job submission, correct?  Then the management app can
see if it wants to subscribe to the Job Edition just published or not.

Alternatively, the monitoring app could poll the SENSE server looking for
Job Editions that are for that user, but the polling would only need
to start when the user submitted a job, and polling of the SENSE server
could stop as soon as the expected Job Edition was published, correct?

With Scheme B, the management app only subscribes once to each printer
Printer Edition
that the user is interested in.  Then the management app has to filter
out notifications for jobs that belong to other users, except ones that
indicate that the other users' jobs are having problems for the user
that wants all printer problems.  In order for such management app filtering
to work, the notification packet would have to have the user name as one 
of the attributes, so that the management app could filter out 
non-interesting notifications, correct?

>a printer problem event occurs.

And if all clients subscribe to all Job Editions, then there are
51*51 notifications generated, so I hope we can avoid that case.

>Tom, does this jive with your thinking?

There are lots of ways to use SENSE for the job submission scenario.
Which one makes the most sense to you.  I'm still pretty new to thinking
about it.

---

From: Jay Martin <[email-masked]>
Date: Thu, 11 Dec 1997 12:41:40 -0500

Tom,

> So we need to understand when a printer publishes an addition.

Do you mean "Edition" (not "addition")?  I'll assume you mean "Edition"
here.

> Does a printer publish a separate edition for each job received?

Well, that's the approach you're taking, so let's say "Yes" and run
with that model for a minute.

> so that a client subscribes to the correct edition(s).

Actually, the name of the Edition does not necessarily have to map
directly to the job id, although it could, I suppose.  I would have
expected to have one or more Edition properties that are used to
map the Edition to the actual Job.

The design of Sense is such that a client can ask for a set of object
IDs (handles) based on a sort of query-filter, where a set of properties
(and possible value sets) can be specified to narrow the target set.
So, the client could ask for the set of Editions (ie, fetch the handles
for the Editions) having a specified set of properties with certain
values.

> editionn for that job, correct?

Correct.  No Vulcan mind meld here. ;-)  The publisher acting on behalf
of the IPP printer would have to create the Edition once it fully knows
about the incoming IPP job.

> Or does a printer publish a single edition for the printer that generates

Sure, we could model Jobs in that manner.  I've given that approach quite
a bit of thought--and could detail a potential design here--but I think
Scheme A is better.  (And I doubt folks would get the time to read the
design for Scheme B anyway... ;-)

> There are pros and cons to each, I'm sure.

Yeah, I guess we could take that route.  I like Scheme A better, at least
right now, anyway.

	...jay