Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Consider other types of Notifications #14

Closed
alechenninger opened this issue Feb 4, 2016 · 2 comments
Closed

Consider other types of Notifications #14

alechenninger opened this issue Feb 4, 2016 · 2 comments

Comments

@alechenninger
Copy link
Contributor

...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.

@alechenninger
Copy link
Contributor Author

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

@alechenninger
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant