feat: event processors #22
Description
Add support for event processors. These will be the ONLY users which can edit/delete events from the history.
These would be automated backends that process the event stream in some way. For example, there might be a use case for an event processor that compacts old events or deletes events that are no longer needed.
These event processors will need to be specific to each application because they will need context on how to interpret the events. It would be difficult to write generic event processors.
Some event processors might not need to rewrite event history. They may just want to consume events as they come in to trigger side effects. For example, sending an SMS message or calling some outside API.
It is quite likely that applications will use multiple event processors. For example, you might use smoketree to process SMS events and some other event processor to handle file storage events.
There will be need to be at least one new API endpoint to allow event processors to update the event history. To reduce potential conflicts, event processors should only be allowed to delete or update events that are at least 60 days in the past. We may make this a configurable setting in the future (either per pocessor or global)
Be VERY careful when updating the ACL design to accommodate event processors. There should be fine grained control over what they can and can not do.
Create a demo event processor in Go.
Future Ideas
The following should be split into separate issues:
- Event processor webhooks. The simple-sync server could call a processor-specific webhook with each new event. This will enable faster feedback from event processors. The first event processors will just have to periodically poll for events.
- Add API endpoint for configuring server settings, including the event processor edit time period