Don, the point is simple. Having such a generic callback will make it much harder to use the callbacks and, more to the point, will make it even less obvious to the developers. I mean, how many functional levels in an API does the developer drill down to if he is to use the API.
Going with your suggestion would mean, that a developer who wants to make an extension as I need it, to look at this procedure, look at the underlying procedures, and find the callback. Once done, he needs to write some code, which, given a rel_id will look:
- is this rel_id present in dotlrn_member_rels_full for every relationship change in a relationship within the system.
- if it is a rel_id that belongs to a dotlrn_member_rel, get the community_id and the user_id.
For me the fundamental issue is, if we are supposed to drill down to the lowest sensible level when adding callbacks, it will make it much harder to read the code and will cause detecting side effects much more difficult. This is why I would limit the scope of a callback and have many of them instead of having a large scope for a callback but just a few.
