Forum OpenACS Development: Re: object_type and content_type

Collapse
6: Re: object_type and content_type (response to 3)
Posted by Lee Denison on 02/05/07 03:08 PM

Gustaf,

Having read the MR proposal it appears to suggest that the incoming email subsystem should:

  1. accept and email (message) of any kind
  2. inspect the email (message) to determine which handler should be invoked
  3. 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?

Collapse
7: Re: object_type and content_type (response to 6)
Posted by Gustaf Neumann on 02/05/07 11:34 PM
Lee,

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

Collapse
8: Re: object_type and content_type (response to 7)
Posted by Malte Sussdorff on 02/06/07 10:15 AM
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.

Collapse
9: Re: object_type and content_type (response to 7)
Posted by Lee Denison on 02/06/07 11:40 AM
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).