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

Collapse
Posted by Gustaf Neumann on
What client API you have in mind? Same as now?

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

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

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

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

Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Emmanuelle Raffenne on
Hi,

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.

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

Don,

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.