Forum OpenACS Development: Re: object_type and content_type

Posted by Gustaf Neumann on

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...

Posted by Malte Sussdorff on
I think we should think about a general mechanism, that is for sure. That should not stop us though from using the callbacks in the meantime. OpenACS is an evolving product. No need to get it perfect right from the beginning. As long as we are aware that we should think about things and that the current implementations are bound to change, I am fine.

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.

Posted by Lee Denison on
Gustaf: I agree that a request processor mechanism which handles all types of request (not just URLs via HTTP) might be nice. Although I would like to see us be explicit about the differences between these channels of interaction, not just the similarities.

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).