There is some overlap with service contracts. The callbacks are meant to be simpler, not involve the database, be geared towards single operations rather than grouped contracts, and come with a built-in method for invoking all implementations.
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.
