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