Forum OpenACS Development: Re: object_type and content_type
A general solution for such kind of problems is a message redirector where a "message" is more or less a synonym for a method invocation. The MR is a generalization for problems where the usage of messages of some kinds cannot and should not be predetermined. For more information, see http://nm.wu-wien.ac.at/research/publications/mr.pdf
If there is interested we could arrange some discussions in the forthcoming .LRN/OpenACS workshop in Vienna, where we can discuss service contracts vs. callbacks vs. object request brokers vs. xotcl to get a better understanding where we could or should move to in the future.
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.
Having read the MR proposal it appears to suggest that the incoming email subsystem should:
- accept and email (message) of any kind
- inspect the email (message) to determine which handler should be invoked
- invoke the handler and provide to the handler the message itself and all information about how it was received
Admittedly the proposal seems to allow for message types to be extended but I think in this case an email is pretty fixed and well defined.
Other than Malte's proposal being more detailed and specific, how does the MR proposal differ from the callback implementation?
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...
I am not fine with long discussions that prevent the immediate work because we say "we need to get the design absolutely right from the beginning". Code is cheap. And it is not like the callback mechanism does us much harm.
So yes, we should have a workshop and discuss the issues, but no, we should not wait for the outcome of it.
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).