Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
14.10.19
-
None
-
Unknown
-
Description
We currently have a very handy TaskConsumer API which allows to create tasks with low priorities to be handled, with a persistency mechanism to ensure that those tasks are resumed if the server is restarted.
However, right now this mechanism allows only to send a DocumentReference and a version for performing a task: any dedicated TaskConsumer won't have other info than those.
It made sense back then since the mechanism was created mainly for indexing (hence the location of this in the index module).
I propose that we improve the design of the TaskConsumer to allow using a map of serializable parameters: this would allow to use the same API for other kind of tasks not directly related to the analysis of documents.
Right now I have already two possible usecases:
1. rewriting of the live email notifications to use a TaskConsumer (right now we have our own dedicated mechanism to with a low priority thread, and also a dedicated mechanism to resume missing emails: we could get rid of that)
2. rewriting of the clean up of notifications filters (it's also implemented with its own mechanism, without resuming of missing clean up)