Tom
At 09:17 11/24/1997 PST, Jay Martin wrote:
>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: 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 --
>----------------------------------------------------------------------
>
>