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

What client API you have in mind? Same as now?

The existing API will not be changed, I'll simply add the two new procedures listed above.

Will it be possible to have for the same package_key a "global" and "instance" parameter?

With the same name? No, names will be unique per package. Of course you can have as many global and instance scoped parameters (of different names) as you want.

Where in the user api will "global" parameter show up?

I haven't decided yet.

Who should be allowed to edit "global" parameters? How can one manage these rights?

I would think only system wide administrators would have that right.

This impacts how we do the web-based admin ui. I'd think that a package instance admin would want to be able to at least *view* the global parameter values, even if not allowed to modify them.

And then there should be a global package parameter UI page in acs-admin for the use by sysadmins.

From the terminology i would prefer "package parameter" and "package instance parameter".

Umm ... all parameters are package parameters. We don't say package_parameter::get because we in the context of OpenACS, package_parameter is redundant. parameter::get is sufficient.

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! :)