Since this is not the first "We shouldn't be specifying these semantics
in BaseN" feedback I've heard, I want to be more clear about what I
meant. I don't believe that BaseN should dictate a canonical
order for interleaving. What I'm trying to explore here is whether we
should have the ability to describe interleaving, and if so
how.
For example, do we want NPs to be able to advertise statements like:
- I will always submit messages for a given topic pattern in the
same order.
- I will always submit messages on individual topics in the same
order, but in the case of a subscription to "A and B", I may interleave
the submissions differently.
- I make no guarantee about submission order. I may submit
messages for separate subscriptions in different orders, even if they
are subscriptions to the same single topic.
(2) Seems like a natural default, but (3) leaves the most latitude.
If nothing else, I think we need to mention such issues, even if only
to say "we make no guarantees at all and can't even talk about such
guarantees in policy." Otherwise, different implementors are liable to
make different guesses as to which of the above (or something else
entirely) applies.
In any case, I think "submit messages for delivery" is the right sort
of thing to say if we're being careful about messaging semantics. The
continuity case makes it clear that there are cases where expected
messages might not be delivered, even given perfect transmission. The
interleaving case shows that ordering may vary even if the transport
guarantees in-order delivery. The notion of "submitting a message"
gives a clear dividing line between the NP's responsibility and the
transport's responsibility, and thus which policies apply where.
Samuel Meder wrote:
On Thu, 2005-01-13 at 11:55 -0500, David Hull wrote:
For simplicity, assume there are only two topics in the world, topic A
and topic B, and that a topic expression may specify any combination
of them. Events are generated in a given order, and we should at
least guarantee that, for a given topic, the NP submits events for
delivery in the order in which they were generated.
Are you saying we should make that guarantee in BaseNotification? I
don't think we should. You can for example easily have a scenario where
a event occurs on a topic but the policy is such that notification
messages are only sent at fixed intervals.
/Sam
The issues here concern whether we should have policy utterances to
describe stronger guarantees.
Suppose that topic A carries notifications A1, A2 and A3, and
similarly topic A carries notifications B1, B2 and B3. At the very
least, we guarantee that A1 will arrive before A2, etc. The first
issue is what to do if there is some inherent ordering across these
event streams. E.g., each carries a timestamp from an external
reference clock. In this case, A1 might be marked as occurring before
(or after) event B1, and the "correct" order of notifications might be
[A1, B1, B2, A2, A3, B3]. Should we provide a way of flagging these
situations, or should we leave that as application dependent.
The second issue comes up when there is no externally-defined ordering
across topics. Should the NP impose one? If two separate
subscriptions both include topic A and topic B, should they see the
same interleaving of messages? This might seem automatic, but I can
imagine a distributed implementation in which different physical
processes handle different subscriptions and so may have different
views of interleaving.
For that matter, under what circumstances is is the original
requirement that notifications should be sent in order of their
underlying events meaningful at all?
|