[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Notification #9: replay in the future consensus point
Andy Bierman <firstname.lastname@example.org> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <email@example.com> wrote:
> >> Note that there is no standard for 'eventClass', 'eventSeverity',
> >> or 'eventTime', and a vendor may choose to use XML attributes
> >> or elements for these fields (if they exist at all).
> > The entire replay feature relies on the presence of an eventTime (or
> > similar). If the manager can't figure out when the notifications were
> > generated, he cannot set startTime and stopTime to get missing
> > notifications. IMO, it's a big mistake that this event time isn't
> > standardized - it means that a manager, in order to use replay
> > efficiently, has to know all datamodels of all notifications, and know
> > where to find the non-standard event time in each one.
> I agree.
> It is a mistake to design the notification message assuming
> these critical standard fields will be retro-fitted in
> an inter-operable manner.
I'm implementing this draft right now, and there are a couple of
things that are awkward, but the main thing that makes it virtually
impossible to do a good implementation of the replay is the lack of
the eventTime (the time the notification was generated).
In my manager, I want to be able to tell if I lost any notifications.
So I get all notifs from the log and maybe listen to the live feed.
If for any reason I can't listen to the live feed for a while, I try
to resync. In order to do that, I use the replay feature with a
startTime equal to the generation time of the latest notification I
received. But there is no standard way to get the generation time
from a notification.
I think that in order to make replay interopable, we need to add the
eventTime to the notifications. Here are two small modifications to
the XSD that will allow this:
As an attribute:
<xs:attribute name="eventTime" type="xs:dateTime" use="required"/>
or as an element:
<xs:element name="eventTime" type="xs:dateTime"/>
Standard eventClass and eventSeverity would be nice, but they are not
crucial to the operations defined in the spec.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.