OK, Im convinced there is no polling. More of a multistep registration
process for (potentially) multiple publications and editions. I would b=
e
more pleased with a single step registration for a single edition whic=
h
directly correlates to MY JOB... unless, of course, I'm some sort of
administrate application wanting job info from multiple devices and rel=
ated
to many users.
I'm probably treading dangerously close to the "in-band" vs. "out-of'b=
and"
topic, again. I know print job destinations may be altered by intermedi=
ate
steps in the print process, like redirection or print pooling. If somet=
hing
is going to insert itself between me and my target, however, and "take =
control"
of the situation, I wish it wouldn't leave it up to me to guess what ch=
anges
it has imposed on the system!
Harry Lewis - IBM Printing Systems
owner-sense at pwg.org on 12/11/97 11:03:55 AM
Please respond to owner-sense at pwg.org @ internet
To: Harry Lewis/Boulder/IBM at ibmus
cc: sense at pwg.org @ internet
Subject: Re: SENSE> Event driven or Polling?
Harry,
Ah yes, I can see where I might have gotten you confused about
polling by a Sense subscriber client. The short answer here is
that the client does *not* poll in any manner whatsoever.
It's tough at this juncture to describe an absolutely concrete
explanation here, since we have yet to define the way to model
and implement a Job in the Sense domain; this topic is currently
being discussed in a separate thread on this DL, so watch that
discussion (and participate!) so we can nail down the details.
In any case, to allay your fears about client polling, let me
try to explain how I think things ought to work, given the
previous example and your comments:
> >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.
>> OK, but this in not what I want to imagine. This sounds like polling!=
Here's a sort of step-by-step sequence of events I would expect
to be handled by such an application using Sense, assuming that
a print Job is implemented as an Edition to a printer Publication:
- Initial operating assumptions:
* The app has been "told by the user" which printers to monitor
(command line options, GUI-managed list, etc...), using some
sort of naming convention
* Similarly, the app has been configured for a target Sense server
- The app registers itself on the Server
- The app requests the list of printer Publications that match the
printer names configured by the user
- For each such printer Publication, the app then:
* Subscribes to the printer Publication so as to receive future
events that declare the creation/modification/removal of
Editions associated with the Publication
* Fetches the current list of Editions, and for each Edition:
+ Fetches the Edition properties that:
- allow the app to discern whether the Edition represents
a print Job, or some other type of Edition
- identify the print Job as being associated with the user
(using whatever mapping method is defined)
+ If the Edition is a Job *and* is related to the user, then
the app subscribes to that Edition, using whatever filter
specs that may be appropriate (ref: the recent discussion
on adding simple event filters in Subscribe messages, etc)
- When a state change happens to the Job, the publisher for the
associated Edition posts an event for the Edition, a copy of
which is sent to all subscribing clients.
- When the app receives the event, it uses the contents to do
"the right thing" for the user (whatever that may be); the event
contains (by its own definition) sufficient information for the
subscribing app to properly handle the event.
- Subsequently, the app may receive an event from a subscribed
printer Publication that denotes a new Edition has been added;
the event message contains certain descriptive information about
the new Edition, such as its class, name, etc.
- Similar to above, the app then goes out and "qualifies" the
Edition (ie, determines whether the Edition is something it
should be interested in), and subscribes to it, if so
- Subsequently, a printer Publication event may be received that
indicates an Edition has been removed, and the app takes similar
steps to determine whether it needs to update the app's state to
potentially remove the Job (ie, Edition) from its internal list
it is monitoring. (Note that there is no need for the subscribing
app to explicitly unsubscribe from an Edition that has been
removed.)
- When the app is instructed to shutdown, it unregisters itself
with the Sense server, which as a by-product, automatically
unsubscribes the client from all previous subscriptions (ie,
the client does not have to explicitly unsubscribe from all
its subscriptions).
So, it should be apparent that *no* polling is ever done, assuming
the model and implementation for print Jobs is as described above.
(This Job model approach is labelled "Scheme A" by Tom in the
related thread.)
Does this make Sense to you? (Gotta love that pun... ;-)
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at 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 --
----------------------------------------------------------------------
Harry Lewis - IBM Printing Systems
=