Forum OpenACS Development: RFC: Callbacks

Implementing this is pretty simple -- the proposal has some initial working code in it, and at the bottom of the proposal are some suggestions from Jeff that make it even simpler.

Before TIPping I thought I'd put this out for discussion again, and get feedback on how this should be exposed.

One question that's come up is how to organize the namespaces. For example I proposed that the implementation proc should look like this:

   ad_proc -private ::dotlrn::callback::acs_user::changing_state {

where "dotlrn" is the home package/module of the implementing code, "callback" is a separator used by the callback system, "acs_user" is the home package/module of the callback entry point, and "changing_state" is the operation name.

Jeff suggested an alternative:

   ad_proc -private ::callback::acs_user::changing_state::dotlrn {

or separator/callback entry module/operation/implementor.

This alternative has the advantage of simplifying the callback system's introspection code, but it means that package implementors are building code in other namespaces besides their own. That may be appropriate given the nature of callbacks.

I don't have much of a preference, actually, but I'd like to hear more thoughts on this and the rest of the proposal.

We could also make the signature be

ad_proc -callback acs_user::change_stat -implementation dotlrn  { ... }

ad_proc -callback acs_user::change_state -implementation dotlrn { ... }

I like it, but just to be clear, we'd be asking them to put these in namespaces, e.g.

namespace eval dotlrn {

    ad_proc -callback acs_user::change_state -implementation dotlrn  { ... }
}

Right? The alternative, asking programmers to use the same fully qualified function name repeatedly across the toolit, seems like a problem waiting to happen.

If we can require that the callback implementations are declared in namespaces, we could conceivably drop the <strike>-callback</strike> -implementation flag and introspect for it.

ad_proc -callback module::op { 
 {-option {} }
 arg1:required 
} {
 docs 
} -

I was also thinking that we could even drop the arg definition for things that are

ad_proc -callback module::op -implementation X

We could barf if there was a callback definition with a proc body.

This works too. Okay, I think we're pretty close.

For one thing invoking things via a callback means you don't know the terminal bit (implementation name) anyway since say for user delete you have:

callback user::delete $user_id

Maybe we should make the above

callback::user::delete $user_id

The proc declaration would not be an issue either way:

ad_proc -callback acs_user::change_state -implementation dotlrn  { ... }

etags --lang=none --regex='/ad_proc -contract \([^ ]+\) -implementation \([^ ]+\) /callback::\1::\2/'

x.tcl,110
ad_proc -callback acs_user::change_state -implementation dotlrn ##callback::acs_user::change_state::dotlrn,8