We discussed this on IRC and ended up discussion the questions:
- Should there be one callback for incoming emails OR should we separate out emails with an object_id TO address into a separate callback?
- Should the incoming email be matched against certain criteria and then dispatched to a specific callback implementation OR should the incoming email be given to all callback implementations in turn?
I believe the answer to question 2 may determine the answer to question 1 so I would like to address that first.
When should a callback implementation be determined before dispatching?
I would say a callback should only invoke one implementation when the event that it is representing is 'owned'. An obvious example is the 'openacs-bugs@openacs.org' example to post a bug to the OpenACS bug tracker. The incoming email is clearly owned by a single package instance.
Given that all packages that want to handle targetted emails of this kind have a limited namespace to play with - namely the TO address, subject line and email body - I would say it makes sense to have a scheme common to all packages which dispatches the email to an individual callback implementation.
When should a callback trigger all implementations?
I would say a callback should invoke all implementations when the event is not 'owned' by the handling code. An example might be a handler which scans the email for DNS blacklisted URLs. Clearly this code doesn't care who owns the email so it makes sense that this handler be invoked indescriminantly.
Conclusion
There are valid use cases for both types of callback - but that line of thinking is dangerous without actual use cases that someone wants to implement. Otherwise the logical conclusion is to add callbacks absolutely everywhere. So I would say we should decide what type of callback we are implementing and do it the appropriate way
As a final thought, if we decide we are implementing both then I think we should have two separate callbacks.