esbtools / event-handler

Notification in, document out.
GNU General Public License v3.0
3 stars 6 forks source link

Consider other types of Notifications #14

Closed alechenninger closed 8 years ago

alechenninger commented 8 years ago

...that produce different results.

@kahowell and I have talked about this a little before.

One use case would be to update config. Currently, we the lightblue impl polls for config changes. But, we are building an event based system... why are we polling?

We could configure a notification to fire on config changes, and the result of that is merely updating the in memory config of the event handler.

This would require different types of Notifications, or a change in the Notification API.

I'm leaning towards the former with something like...

Obviously, in that model, everything could be a CommandNotification, but in code this shows up mainly as what other pieces of the system does a notification implementation have to know about. For instance, if DocumentNotifications were implemented as commands, then the implementation would have to know about the document even repository it is supposed to persist to, as well as how to update a notification store based on the results of that persistence, and last but not least you would have difficulty batching lookups as part of creating the document events. So, clearly in this model it would be better to use the closest, most specialized type for a notification use case.

So, in this scenario you'd have a ConfigNotification implements CommandNotification and you would have to either give it the config to update as part of parsing the notification entity, or make the command notification API accept arbitrary dependencies... that would need to be worked out a bit.

alechenninger commented 8 years ago

I think actually I am implementing this kind of thing in #21

alechenninger commented 8 years ago

Let's continue the generalization discussion in #50 since actually I think some communicated 'thing' that can 'do something' that fails or succeeds (process()) and can be optimized together (isSupersededBy and canMergeWith) can work for all of notification, documentEvent, and message constructs