Re: Events, Subscriptions, Link Bindings, and RESThooks

Hi Michael,

there is a lot of confusion about "events".

Some applications are indeed interested in events, as a stream of points
in time at which something happened.  Sales are good examples of events,
each sale has its own identity, and you'd rather not lose any single one
of these events.  E-mail messages are another example for that.

Many applications that are sometimes described as "events" are really
just about changing state.  What you really want to know is the state;
for these applications you don't need every single state change.  You
may even need to define thresholds for notifications, because the state
changes in minute ways too often.  Making the threshold leads to a
notification, but is not an "event".

Variable state is often best described as a time series, where the
points in time where the state is sampled are more or less arbitrary.
Again, these samples are not "events".

If all you have is a hammer (your processing is based on message
queues), everything is going to look like a nail.
So if all you have is events, you may need to map notifications and time
series into events.

State changes and time series have one property that events don't: they
scale.  If you don't have the capacity to process the state change
information at a fine grain, you can go to a coarser sampling period, or
combine multiple state change notifications into one.
Obviously, coarser scaling loses some information; if the state is the
amplitude of a microphone signal, and you increase the sampling period
much above 0.125 ms, any speech input will become less and less
intelligible.  Still, each single sample in a time series is not an "event".

Sometimes we turn time series into events: A button press generates an
electronic signal that has a few bounces and then settles into a
different state for a short while before the button is released.  A
debouncer processes this bouncing signal and tries to derive countable
events from that.

In this particular case, the events can usually be translated back into
a time series by just monitoring the count of button presses so far;
this allows collapsing all the events into a single state variable
again.  But that is not true of all events that might be generated from
a time series:  E.g., e-mail messages can be converted into a mail
archive, which is again just a piece of state, which however this
doesn't have the nice collapsibility property.

I would prefer if we discuss these different kinds of information
separately, and only talk about "events" where each of these has a
clearly separable identity in the application being discussed.

Grüße, Carsten

Received on Wednesday, 27 April 2016 07:22:35 UTC