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@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 wrote:
>
> Jay, I've started trying to follow the SENSE discussion about job events and
> came across this...
>
> >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! You went
> on to say...
>
> >Whenever a Job Edition is found that appears to be related to
> >the user, the app subscribes to the Edition.
>
> Great, event based from that point!
>
> I may be reacting to something that was only meant to be illustrative to the
> discussion.
> Do you really expect Sense based job Monitoring to require applications to
> poll for editions?
>
> Harry Lewis - IBM Printing Systems