SENSE Mail Archive: Re: SENSE> SENSE Req review

Re: SENSE> SENSE Req review

Tom Hastings (hastings@cp10.es.xerox.com)
Fri, 14 Nov 1997 12:11:36 PST

At 10:50 11/06/1997 PST, Jay Martin wrote:
>> 4. (#14) Client ACK of event. I'm not sure this should be required in all
>> cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate
(#16) -
>> server resource management. The server can really bloat while waiting
for ACKs
>> from clients who disappear etc. It is feasible to consider an
"unreliable" mode
>> of operation.
>
>Excellent observation, Harry. We, too, have found that an "unreliable mode"
>is certainly viable in certain environments. This shouldn't be too hard to
>add to Sense. Do others have any comments on this addition?
>
>Right off the top of my head, I'd say that the subscription request would be
>defined to have one or more message properties indicating the level of
reliability
>for events delivered for that subscription.
>
>The client API in the current implementation actually supports the kinds of
>reliability controls you mention. However, these controls are used across
the
>client session and can not be altered on a per-subscription basis.
Perhaps such
>session-wide controls are enough for you, though.

I agree that the subscriber should be able to indicate whether he/she
want reliable or unreliable. (It shouldn't be a propertly that only
the publisher sets.)

I thought that there was a property in the edition that specified the
number of re-tries before giving up. Since there must be a separate
counter for each subscriber to keep track of how many retries have been
made, couldn't the subscriber also specify the number of retries when
subscribing?

A value of 1 would mean unrealiable.

>> 5. (not addressed) The requirements do not appear to directly address
the need
>> for filtering. I know the requirements do not address data content and
it could
>> be argued this is where this topic belongs, but I think filters are
significant
>> to any event based scheme and should at least be mentioned. I also
acknowledge
>> that filtering is exactly one of the reasons the current SENSE
architecture may
>> appear somewhat less than simple (my comment 2, above).
>
>Ah yes, filters. As I described in Boulder last week, filters, or more
precisely,
>filter specifications, are one of the primary reasons we conceived of the
notion
>of an "Edition". Filter specifications can get very, VERY ugly, and
before you
>know it, you often end up designing an entire "language" to deal with that.
>
>This is something we at Underscore desparately wanted to avoid. I'll address
>that issue in more detail in a later message. However, for now, suffice to
>say that a requirement exists for a client to be able to specify receipt
of only
>a subset of all events that may be available from a given source. Exactly
how
>that "subset" is defined and handled is a topic for design and
implementation,
>IMHO.

Yes, allow the subscriber to specify a simple subset of the 6 defined
events (actually only 4, because 'all' and 'none' are really separate
events).

In IPP, we defined the following set of events and allowed the client
to specify any combination of them. That doesn't sound too difficult.

Part of a publication should be a single property which is the names of
the set of possible events. The subscriber specifies a property which is a
subset of that publication property.

Here is the following text from the 10/14/97 Model draft (that was
subsequently deleted because of a lack of a transport for the events).

4.2.2 notify-events (1setOf type2 keyword)

This attribute specifies the events for which the end user desires some
sort of notification. The "notify-addresses" attribute is used to describe
the destination addresses for these events.

Standard values are:

'none': the Printer SHALL not notify.

'all': the Printer SHALL notify when any of the events occur.

'job-completion': the Printer SHALL notify when the job containing this
value completes (i.e., enters the 'completed', 'canceled', or 'aborted'
state) with or without errors.

'job-problems': the Printer SHALL notify when this job has a problem
(i.e., when the job leaves the 'processing' state and enters the
'processing-stopped' state).

'job-started-processing': the Printer SHALL notify when the Printer starts
processing the Job (i.e., when the job leaves the 'pending' state and
enters the 'processing' state).

'printer-problems': the Printer SHALL notify when this job is affected by a
Printer problem. This happens when the printer enters the 'stopped' state
while this job is in the 'pending', 'pending-held', 'processing', or
'processing-stopped' state.

In a create request, if the client supplies 'none' along with any other
combination of values, it is the same as if only that other set of values
had been supplied (that is 'none' has no affect). If the client supplies
'all' along with any other combination of values, it is the same as if only
'all' had been supplied (that is 'all' subsumes all other values).

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