See my replies preceded by TH>
Marty wrote:
1B. Base Notification Spec: Clarify that the Printer MUST send Event
Notifications for any given Subscription Object in time stamp order,
but MAY interleave Event Notifications from other Subscription
Objects
MJ> I think that 1B means that all events are ordered, regardless of what
subscription they came from, at least that's what "interleave" implies.
TH> But the interleave is a MAY, not a MUST, for the Printer.
That would differ from the original proposal that they be sorted
chronologically within subscription groups. On looking below at the
proposed text for this, it's saying that events can either be sorted
chronologically regardless of what subscription caused them, or that they
can be sorted chronologically in groups by subscription. You might as well
say that they can either be sorted or not, since
sorted-within-subscription-groups requires as much work at the client as
sorting unordered events.
TH> Simple Notification Recipients are only dealing with one Subscription
object, so that advantage of having the Printer sort by time-stamp for the
events for a Subscription object, is that the simple Notification Recipients
would get all events ordered and wouldn't have to sort. Only complex
Notification Recipients that are getting notifications from multiple
Subscription objects would have to sort with 1B.
MJ> 1C. The 3rd option is that events be ordered, which I think makes more
sense than 1B, although I'd prefer 1A. 1B puts sorting onto the client,
and if you're going to do that anyway, you might as well go with 1A.
TH> Requiring strict ordering without allowing interleaving is a strict
impossibility. In the two Subscription object in the proposed text, the
Printer would have to wait until the job completes before sending the
Printer events for another Subscription object, but the Printer jammed so
the job will never complete, until the Printer is unjammed.
This archive was generated by hypermail 2b29 : Wed Jul 18 2001 - 12:52:24 EDT