...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...
DocumentNotification: What we currently use. Produces document events.CommandNotification: Very generic... implementation "does something" when processed.
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.
...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...
DocumentNotification: What we currently use. Produces document events.CommandNotification: Very generic... implementation "does something" when processed.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, ifDocumentNotificationswere 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 CommandNotificationand 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.