Forum OpenACS Development: Re: object_type and content_type

Collapse
3: Re: object_type and content_type (response to 2)
Posted by Gustaf Neumann on 02/03/07 08:22 PM
Talking about callback is not the right kind of abstraction for this problem. A callback is more of a implementation technique than a design technique.

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.

Collapse
5: Re: object_type and content_type (response to 3)
Posted by Lee Denison on 02/05/07 12:26 PM
Gustaf,

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.

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