On Sat, Sep 12, 2009 at 9:38 PM, Marc - A. Dahlhaus <mad@wol.de> wrote:
How to solve the other problems that i spotted in the hook design draft?
I think these problems are the same for hooks and triggers, and they can both be solved.
<quote> Also i still have the opinion that the configuration of a hook-script should be contained in the script itself as this is the only way that i could come up with at the moment that would activate the hook automatically on installation of the hook. Another way would be to add the hook configuration into the database and parse this info from there. But the user created hooks would only work if the user builds his own hook-package then...
packages could just install filehook config in a hook.d directory
Another problem with hooks and the points on which they should be executed is that if you have a large transaction in which some packages add hooks that are needed for packages that are installed in the same transaction need to be parsed on installation time to give you the option to run the hooks on the point they should be executed. Also what about a package that wants hook X needs to be installed before the hook X is added by another package? Would be a classic chicken-egg problem i think. Triggers like i proposed them don't have this problem as they get executed after the transaction is completed. At this point all triggers are where they should be. </quote>
filehooks can also work at transaction level