Re: Events, Subscriptions, Link Bindings, and RESThooks

Hi Carsten,

I see your point. I have to varying degrees used "event" to mean a source of notification, be it state changes or new distinct items. I've also been considering using the "EventSource" feature to emulate observe over HTTP for web applications. I agree it would be good to clarify the difference. I think you also mentioned that sometimes state changes can't be lost. They could then be considered events?

My main idea is that both state changes and events may be modeled as notifications emitting from a resource location, and thus be monitored using Observe, or bound to another resource with a link-resource binding that transfers state conditionally according to the binding instance configuration. Events would often not be filtered but could be, e.g. email priority flag or header filter rules. 

In the case of link-resource bindings of bona fide events, the resource they are bound to would probably need to be a collection, and the method used would customarily be POST. This way, new events would be added to the collection and could be Observed, retrieved, or re-bound to another resource. State changes might be propageted using PUT in some systems, but not likely events.

The common part is Notifications, but the sources could be either events or state changes. 

Best regards,

Michael


> On Apr 27, 2016, at 12:22 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 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 Thursday, 28 April 2016 02:38:30 UTC