Forum OpenACS Improvement Proposals (TIPs): Re: TIP #141: Implement true global package parameters
If it won't be possible for one parameter to be global and instance scoped at the same time, the two new procs are not necessary (or they could be private ones called by the existing ones when scope = global).
It'd be simpler, safer and more robust to slightly modify the existing parameter::get|set_value|(get|set)_from_package_key procs.
The only reason singleton services are instantiated are so their parameter values can be created.
If you call the get/set_from_package_key procs with the package key for a non-singleton package that has multiple instances, you'll get an error since the db_0or1row call inside db_string will return more than one row.
It's particularly nasty because if you make this mistake and test on an install where you've only created/mounted one instance of your package, it will work great.
Mount another instance, boom, your package dies.
So moving to a world where singleton, non-mountable services have their parameters declared global and aren't instantiated is in the back of my mind, and facilitating that path seems easier by providing a new API call. It would make it much easier to track down/weed out the old get/set_from_package_key calls later package-by-package, grep-by-grep.
That's my thinking, anyway. Of course, I may be living a fantasy to think that getting rid of needless package instantiations will ever really happen! :)
I didn't realize you wanted to deprecate get/set_from_package_key procs, sounds like a good idea to me. Would be nice to take advantage to make the API more consistent, i.e. renaming parameter::get to parameter::get_value :). I still think that using the same API (parameter::(get|set)_value) for both global and local parameters is the way to go.
Regarding the user interface, parameters for services can be set from the main page of the site wide admin. Since those are global, this could be the place to set global parameters for both service and application package.