"why not first change your own request processor and see how well it works for you"
Because I try to collect feedback from the community before I head in any specific direction, especially when it comes down to coding changes into core. And as you can see from the discussion it sparked, my "implementation" would not have been one generally acceptable.
In the past the change I thought off would work when you wanted to change the login screen for users in acs-subsite/lib/login.adp. I managed to make the location of this file a parameter in 5.4 and now you can store that file in a custom package. I did it this way because none of my clients wants the default login.adp, therefore general usefulness is implied.
But what if a client has changed /acs-admin/www/admin/become.tcl to make an additional permission check for special sysadmin privs which they have in their custom application. None of my other clients wants this. It is not generally useful in OpenACS (I'd assume), so the only options at the moment I have is:
a) Make the location a parameter (yet another one?)
b) Write a callback so others can make additional checks if the want to
c) Rewrite their whole handling of permission checks for sysadmins to just use ACS permissions (they would not pay for that)
d) Fork and always remember there is a change in that file when merging new versions from OpenACS
e) Write /www/acs-admin/admin/become.tcl
a-c) Do not make sense.
d) Is something I would like to avoid and be it for the reason that the client could by accident say "update from repository" and overwrite the change.
Doing d) has the benefit that, when a new version comes out and you use a clever merging tool then chances are that you will not run into any problems and still retain your custom changes. At least for a minor change like this. But what if your whole page has changed? Then it might be better to have a custom version of the file and just look at the changes in the OpenACS version and modify if needed manually.
e) Works beautifully (thanks Don for reminding me about that), but only in packages that you mount *once* (otherwise you would have to do it for every mountpoint).
I have seen client installations where a custom package was used and they included the OpenACS functionality. That works as well, but provides a lot of code and makes code maintenance more difficult (as you need to copy files which are not really needed as well, just to make the custom package provide the minimal functionality needed). At least I initially got confused which package is used and mounted when working on that site.
So the idea of Don's appeals to me most at the moment and if there is the time I will probably investigate it a little bit more. For the time being and my immediate needs I am fine with option e), though I would like to come up with a general plan (best practice) on how to do these kinds of customizations / forks you name it.
