Forum OpenACS Improvement Proposals (TIPs): Re: TIP #141: Implement true global package parameters

Posted by Don Baccus on
Well, my goal is that the get/set_from_package_key procs should slowly disappear.

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.