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.
>
>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.
This is scheme A.
>
>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.
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?
>
>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.
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.
>
> ...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
>> >
>> >
>> >
>> >
>> >
>
>