Refactor code: steps vs policies
Closed this issue · 3 comments
There could be a more clear distinction between a processing step and policies.
Right now, every 'step' in the e-mail processing is called a 'policy'.
It would make more sense to have these definitions:
- step: a step is a phase where an action executed in the e-mail processing. Examples are: finding the caller, creating or updating the ticket, checking policies, performing a custom action, ... It is the kind of current 'policy' which now always returns 'true' when the
IsCompliant()method is called. - policy: a policy is actually a specific type of step which might cause the e-mail processing to be aborted. It can occur before any step.
Initially some backward compatibility methods may need to be added. Also the $iPrecedence order would be shared, which further advocates the idea of policies being a subclass of a step; where some assumptions may be made by default instead (although "behavior" is often present, "bounce subject" and "bounce message" are not. Consider whether this should also be a subclass of a policy)
Alternatively, there could be an interface iStep which replaces iPolicy; and two abstract classes to extend (one being Step and one being Policy, possibly a subclass of Step).
The new idea is simplification. A lot of steps are added, which aren't enforcing anything (so not really a "policy").
A step would also have a rank and be able to by default print some input before and after execution. Some methods would need to be renamed though.
A policy would be the same as a step, but on top of that it could block further processing of the e-mail.
There's no functional benefit for now to start working on this.
Functional benefit: in some scenarios, steps can be performed (e.g. create IMAP folder) which take a bit of time to properly synchronize. This could indeed be queued and so on, but indefinitely queueing risks breaking the mail processing and causing it to hang.
It would be nice if there could be some attempts, after which the processing continues; and just keeps the e-mail as unprocessed (so it's attempted again next time) rather than assigning another unwanted status to it.
A sort of "timeout" would also be nice to have.
Another point to consider: a step should be able to completely suspend the ongoing e-mail processing.
Use case: in the first run, a step may perform an action which takes some time (e.g. create new mail folder, call an API, ...) which takes some time to finish. Rather than implementing a wait; in some cases it may be best to abandon the current execution of mail processing altogether.