Subject: SENSE> New proposal for Server-based event filtering

From: Jay Martin <[email-masked]>
Date: Mon, 24 Nov 1997 12:17:51 -0500

I've given a lot more thought to the notion of client-side
specification of event filtering for a given Edition, based
on the recent thread between Tom Hastings and myself.

I guess I can support the notion of lightweight event filtering
(done by the Server, based on the client spec at the time of
subscription to an Edition), as long as we keep it *simple*.

Here's what I propose:

  a) A new standard Edition property called "Event.Classes"
     is defined, where the value consists of one or more named
     event classes supported by the Publisher.  The Publisher
     alone controls the names of those event classes.

  b) A client MAY specify Server-side event filtering by adding
     a new message property called "Event.Classes" in the subscription
     request, where the value of the property is a set of named event
     classes; if this property is not present or has a null value,
     it implies the client desires to subscribe to all event classes
     that may be supported by the Publisher of the target Edition.
     (In effect, this is how the current Sense implementation works,
     although it should be mentioned that backward compatibility is
     not essential from my perspective).

  c) Upon issuing an event message to the Server, a Publisher MAY
     include the "Event.Class" message property signifying the event
     classes associated with the event.  If this message property is
     not specified in the event message, then it is assumed the event
     is related to all event classes supported by the Publisher for
     that Edition (again, this how Sense currently works).

  d) Upon receiving an event message from a Publisher for an Edition,
     the Server will forward copies of the event message to all
     Subscribers if their subscriptions included the specifically
     named event class that matches that provided by the Publisher
     in the event message.  If no Event.Class message property exists
     in the event message, or if the value of that property is null,
     then the Server will forward a copy of the event message to all
     Subscribers having specified the equivalent of "all" at the time
     of subscription.

  e) A Subscriber may alter its desired set of event classes for an
     existing subscription by sending another Subscribe request,
     in which the contents of the subscription contain a new value
     for the Event.Classes message property.  The Server, upon
     realizing that the client is already a Subscriber to the target
     Edition, will update the current subscription such that the new
     Event.Classes property value overwrites the previous value.  If
     the Event.Classes property is not present or null in the new
     Subscribe request, the Server assumes the client desires to
     subscribe to all event classes defined in the Edition.

Now, using IPP as a target concrete example, I would propose that
an Edition used to provide IPP job events could be defined to have
one or more of the following named event classes as the value of
the Edition's Event.Classes property:

  job-completion
  job-problems
  job-started-processing
  printer-problems

A null (or missing) Event.Classes property implies all known IPP
events are supported as defined for the Edition (whatever that may
be).

For example, let's say an IPP Printer Publisher has defined an
Edition that provides some--but not all--of the currently defined
set of IPP job events:

  Event.Classes=job-completion,job-problems,job-started-processing

If a client desired to subscribe to that Edition, but only wanted
those events pertaining to the completion of jobs, then the client
would send a Subscribe request that included the following message
property:

  Event.Classes=job-completion

If the Publisher then issues an event where the message includes
the following message property, then the Subscriber would receive
a copy of the event:

  Event.Classes=job-completion

If the Publisher issues an event with the following message property,
then the Subscriber would NOT get a copy of the event, since the
Subscriber did not specify the equivalent of "all" when subscribing
to the Edition:

  Event.Classes=

(That is, the value of the "Event.Classes" message property in the
event message is null, or perhaps missing.)

What do folks think about this proposal?

	...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   --
----------------------------------------------------------------------