Subject: SENSE> Event driven or Polling?

From: Harry Lewis <[email-masked]>
Date: Wed, 10 Dec 1997 17:15:23 -0500

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

---

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

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:

> 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:   [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   --
----------------------------------------------------------------------