Forum OpenACS Development: Re: Require TIP for callbacks?

Collapse
Posted by Malte Sussdorff on
Dave, I totally agree with you about the strategy. Here is mine:

a) Have multiple callbacks in clearly defined places with a limited range of possible interactions.
b) Create the callback in the highest level procedure where it is needed instead of deeply buried right before the DB insert (so write one for group::add_member instead of the generic relation_add).
c) Always call all implementations. Do not arbitrarily limit the callback implementation calls. That makes it useless in custom packages.
d) Have as many callbacks as possible so I do not have to fork from OpenACS for a client applications different behavior.

I know the last statement is probably contradicting most of the developers in the community, but I am sick and tired of maintaining 15 different code bases at the same time, just because a client needed a small change here and a small change there. That's why I introduce callbacks. Because it allows me to keep custom code separate and commit improvements to OpenACS much quicker.

Collapse
Posted by Gustaf Neumann on
I am one of the people disagreeing with (d), but i certainly do agree that openacs would profit much from having better ways to manage/store installation assets (configurations, local changes, as called in product line architectures variants and variability points).

Openacs is already quite good in managing core assets (packages, versions, dependencies) via the database. A development towards managing the installation assets over the database would be great and could certainly ease change management for installations significantly. However, to implement such product lines require architectural support and guidelines how to handle and track local modification in which situation to standardize the change management. The support should as well contain support for testing of the adapted installation assets.

Callbacks were primarily invented for disruptive control flows (e.g. in event handling, application semantics for GUIs), not for configuration issues. Be aware, that many problems we have today in configuring oacs can be handled with standard oo techniques such as subclassing. On top of that the strengths of xotcl are in terms of flexibility through mixins and filters, which are means to implement e.g. aspect oriented constructs. So, we are in a good shape to build a really good environment to handle installation variability. On the short range, callbacks are maybe a good tool to handle variability now. On the longer range, they won't make it easier for the sketched next level.

Collapse
Posted by Tom Jackson on
Gustaf, I think the description of how xotcl would handle this is more in line with what I was thinking a callback was used for. OpenACS seems to use a named callback system which triggers inside of a procedure, and therefore requires source code modification. Obviously this changes the behavior, otherwise you wouldn't need to add the callback.

Since Don has reminded everyone that query-writer will never be used in OpenACS core (thank god, I'd hate to fight against changes to it), I'll just mention that query-writer is even closer to the CLOS system than xotcl in this respect. query-writer uses generic functions for new/set/del/rst operations. At the moment there are only a few callback points. One just after all the input attributes have been validated, but before the object operation. This is used to do cross attribute validation or to otherwise combine attribute parts into one. There is also an original block of code that can be run just before the object action. Another point is just after the object action.

It looks like xotcl could be used in a similar way around any proc. Both method lends themselves to reducing code complexity. I'm not sure that adding callbacks _into_ a proc body achieves the same goal, personally I can't tell the difference between that and just inserting a new function call inside the procedure. Regardless, neither could be called configuration. Calling two things (or behaviors) by the same name is usually the beginning of disaster. Probably worse than having to maintain 15 different versions of code is constantly having to having to adjust code which used to work perfectly well, but now doesn't.

Collapse
Posted by Gustaf Neumann on
i have never heard about query-writer before (this discussions happened at a time before i looked in openacs), but found some forum-posts about it. it seems to me as an interceptor for the life-cycle and accessor functions of acs-objects on the database layer. Is this right?

Using powerful language constructs can be very constructive or very distructive. Some languages are designed to limit the harm, a bad progammer can do. Some other languages are designed for empowering the power-users. xotcl was certainly designed for the seconds category, where a good design can be achieved with a few statments (the initial goal was to provide language constructs for design patterns, for adding and removing these dynamically). no language guarantees quality, quality control is needed always. It certainly makes no sense to use every language construct in every situation.

My point was not to talk about xotcl, but about product line architectures, about ways to manage variablility in code installations, which is a serious problem in complex real life situations.