I've thought about the callback approach in the past but it seems complex and doesn't remove the need to scatter random integrated application actions in our vanilla code. However, I'd greatly prefer it to the certain approach, because it boils down to the code having to ask whether or not a callback is defined for a specific action, rather than asking "is .LRN her? is .WRK here? is .BlahBlahBlah here?".
For the case at hand I suggest Janine just change .LRN to use its own membership state change script. .LRN totally redefines what being a user means with its predefined groups, etc. Anyone writing code that changes fundamentals to this extent should be prepared to supply custom scripts to support such changes, IMO.
On the other hand, there are other minor changes to file storage made by Sloan that aren't going in because they're .LRN dependent.
My current position is that
1. Sloan's .LRN specific code isn't going into our non-.LRN packages (in my role acting as arbiter for Sloan, at their request)
2. I don't have a clean solution for allowing such customization
It's #2 I'm concerned about ...
Malte - replacing functions based on alphabetical order is a kludge, I really don't care for approaches of this sort. Though it happens to be exactly what I did for Greenpeace Planet when faced with the same problem :) ("G" follows "A" in the alphabet just like "D" does)
