Forum OpenACS Development: Re: object_type and content_type

We discussed this on IRC and ended up discussion the questions:

1. Should there be one callback for incoming emails OR should we separate out emails with an object_id TO address into a separate callback?
2. 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.

I agree callbacks are an implementation technique - I was talking in terms of callbacks because their use was predetermined in Malte's proposal. If you would like to abstract my suggestions you should simply read it and replace each instance of the word 'callback' with the words 'message handler'.

The discussion of 'service contracts vs. callbacks vs. object request brokers vs. xotcl' is an escalation to a much more general problem and probably won't help Malte very much in a practical or short term sense.

I notice that the document you linked presupposes an object oriented methodology - whilst object orientation has a lot of popular support in the community I don't believe there have been any concrete proposals of how to map the functionality of OpenACS to an object oriented design. Nor have there been any discussions of how we might resource such a conversion or what timescales we might aim for. I think it is unreasonable to prevent Malte from introducing a very useful capability because we haven't decided whether to switch the whole of OpenACS to an object-oriented paradigm.

just a short answer (i am currently in the alps skiing).
it looks to me that we have two different kinds of problems to solve:

a) how to dispatch certain messages to different kind of consumers (e.g. packages, or acs-objects) and

b) how to address certain services via email. This is a typical remoting problem,

it makes certainly sense to think about the more general problem. In the best of all possible worlds, i would like to see a dispatch mechanim, that is able to handle dispatch via URLs (request processor), dispatch via SOAP, and dispatch via email (and maybe different interfaces). all these dispatch mechanisms require similar services, like permission management or package resolving, etc...

I can't offer a detailed design, but i think its worth to think more on the architetural level, which offers various patterns for such kind of problems. we will try to prepare something in this direction for our workshop...

Malte: I agree that this architectural thinking should not stop work which you are clearly willing to do in the immediate future. I don't think an architectural change should affect current work until it has been proposed, demonstrated, agreed and resourced (usually in that order).