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

Collapse
1: TIP #141: Implement true global package parameters
Posted by Don Baccus on 01/30/10 02:48 AM
This has been a long-term annoyance in OpenACS, about to be made worse by some extensions to the package model I'm implementing for MGH (the subject of a future TIP).

I should hope this TIP is self-explanatory ... if not, look at file-storage and ponder several of its parameters, such as which program to be used to archive file storage contents.

Essentially I'll add a scope attribute to apm_parameters, 'global' or 'instance'.

'instance' will work as all parameters do today, and all current parameters in an install will be upgraded to have this scope by a kernel upgrade script.

'global' parameters will not be associated with a package_id, and two new procs, parameter::set/get_global_value will be provided.

Collapse
2: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Dave Bauer on 01/30/10 03:29 AM
Approve!
Collapse
3: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Gustaf Neumann on 01/30/10 10:48 AM
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
4: Re: TIP #141: Implement true global package parameters (response to 3)
Posted by Don Baccus on 01/30/10 04:58 PM
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
5: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Torben Brosten on 01/30/10 06:03 PM
Aren't kernel parameters essentially global or at least in the appropriately shared context?

Why not establish "global" parameters by declaring them in acs-kernel?

Identifying external services (tar gzip gunzip etc) this way would:

1. be easier to manage on sites with multiple package instances.
2. provide a consistent set of values for code regardless of package referencing them.
3. prevent needing to expand the api list.
4. reduce time on diagnostics by having to consider yet another attribute of the system.

Collapse
6: Re: TIP #141: Implement true global package parameters (response to 5)
Posted by Don Baccus on 01/30/10 06:51 PM
You're explaining how things work now, if one wants to specify a "global" package-specfic parameter. Currently if I have an includelet package (for instance) and want to provide a parameter for it, I have to declare it in an existing singleton package, most likely acs-kernel. Or declare the includelet as a singleton service so it will be instantiated for the sole purpose of providing a package_id to hang the parameter value off of (which can then be broken if someone mistakenly mounts the package).

Getting rid of this kludge is the entire point.

Collapse
7: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Michael Steigman on 01/30/10 10:24 PM
Approve.

And I like the global/instance nomenclature. Very appropriate. The globals should probably appear as inform values within an instance in a separate "global" section. I don't feel very strongly about this but it seems like it could be confusing to allow even SWAs to edit global params from an instance. A link to acs-admin for SWAs would make sense, though.

Collapse
8: Re: TIP #141: Implement true global package parameters (response to 6)
Posted by Torben Brosten on 01/30/10 11:18 PM
If I want to change the value of a global parameter that is set somewhere (unknown), where would I go to find out where it is set?
Collapse
9: Re: TIP #141: Implement true global package parameters (response to 8)
Posted by Don Baccus on 01/30/10 11:29 PM
In someone's code, you mean? grep for "parameter::set_global_value" and look for the package key, just as you would today for pseudo-semi-not-really global parameters that are set using "parameter::set_from_package_key".
Collapse
10: Re: TIP #141: Implement true global package parameters (response to 9)
Posted by Torben Brosten on 01/30/10 11:46 PM
I mean as a sitewide admin, nondeveloper, who wants to see or change the global parameter value.
Collapse
12: Re: TIP #141: Implement true global package parameters (response to 10)
Posted by Michael Steigman on 01/31/10 12:00 AM
They would show up in the site wide UI Don has mentioned but would also be visible inside a package instance (perhaps with a link to the page where you can edit in the SW area).
Collapse
11: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Torben Brosten on 01/31/10 12:02 AM
I'm not an acs kernel developer, and so perhaps my voice stands more for those who don't walk around with the entire OpenACS API and sitewide web UI at their fingertips ie newbies, web admins etc.

Why not create an acs-global-service package to throw all the non acs-core dependent parameters etc into?

This would be a great place to put code that is shared between optional packages and not used by core, while preventing extraneous references in the core.

Collapse
14: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Dave Bauer on 01/31/10 05:57 AM
Torben, this would still end up under /acs-admin/

Basically acs-admin will have a list of packages and the global parmeters for each package will be set there. This way the parameters that affect a certain package are in the right place.

Collapse
13: Re: TIP #141: Implement true global package parameters (response to 6)
Posted by Torben Brosten on 01/31/10 06:13 AM
This seems like a patch to a symptom that disrupts part of the structure of the system by adding more complexity instead of fixing the circumstances associated with the original problem. It's so much easier to add something new instead of going back and cleaning up what has already been done.

It seems, responsible development would consist of going back and cleaning up the code already developed.

This proposal doesn't address the parameter problem where a package takes it's default parameter values from the package.info file for each new instance global or not.

Why not add an optional attribute or two to the package.info parameter tag that denotes where to get the new instance value from, the .info default or a previously instanced version of the package (denoting either the first or the last case of the package's instances to cover various use cases) if available?

Either way, the one acs-global-service non-core package seems like it would be useful for other things, too. What's the big deal about having a shared service package? Each portlet has been getting it's own package designation for awhile, thereby fragmenting a package to sets of packages. An acs-global package would be a positive step in pooling these shared code and environment variables.

Collapse
15: Re: TIP #141: Implement true global package parameters (response to 1)
Posted by Torben Brosten on 01/31/10 07:22 AM
I appreciate everyone's response to my concerns.

The comments are in the spirit of working toward a tightly running OpenACS kernel instead of being like a gob of half-implemented ideas that seems to be a prevailing interpretation sometimes.

Please continue to give it your best. OpenACS is a leading technology and deserves it.

cheers!

Torben

Collapse
16: Re: TIP #141: Implement true global package parameters (response to 13)
Posted by Dave Bauer on 01/31/10 05:01 PM
Ooops,

Jeff Davis already TIPed this a long time ago. It was approved but not implemented.

Don, do you think Jeff's ideas add anything to your proposal?

Torben,

This is a concrete example why we need gloal parameters. File storage has a paramter for the maximum upload file size. I have never had a site where this made sense to be instance specific. Generally this is an issue for long lived sites where the average file upload size increases as newer types of files are used. ie: IN the past videos were not common but now videos in the hundreds of megabytes are uploaded on some sites. This file storage paraemter is specific to the file storage package, but should be set site-wide in one place. In some dotlrn installs there are hundreds of file storage instances.

Collapse
17: Re: TIP #141: Implement true global package parameters (response to 16)
Posted by Don Baccus on 01/31/10 05:20 PM
Oh, that's funny, Daveb, we've discussed it in the past but I hadn't realized it had gone that far!

Now, since you found it, and I'm lazy - what TIP # was it?

Linky linky please!

Collapse
18: Re: TIP #141: Implement true global package parameters (response to 16)
Posted by Torben Brosten on 01/31/10 05:28 PM
Dave,
I've always wondered why file-storage didn't get the maxfilesize value from config.tcl for consistency since it is bound by that value anyway.
Collapse
19: Re: TIP #141: Implement true global package parameters (response to 18)
Posted by Nathan Lunt on 01/31/10 06:02 PM
In that case, I'd rather see config.tcl have some outrageously value and let file-storage reign it in.  This way admins aren't confused as to why uploads are failing even after they've updated the parameter. (A bit off-topic, but still.)

Don, that global parameters feature would be a god-send for those of us that have many instances of some packages.  The way I pictured your implementation is that each package would see an uneditable value for global parameters, but that makes me wonder how you would handle any package-specific overrides.  Then, if you have admins overriding global parameters on a per package basis, they've defeated the whole point, right?

I guess what I would suggest is the admins should be able to override the values per package, but they need to see an explanation of why it's not a good habit to get into.  Additionally, it might be a good idea to have a list of packages that have overridden values on the page they set global values.

Collapse
20: Re: TIP #141: Implement true global package parameters (response to 17)
Posted by Dave Bauer on 01/31/10 08:08 PM
Previous TIP about parameter scope
https://openacs.org/forums/message-view?message_id=271910

Oops it was still in my clipboard!

Collapse
21: Re: TIP #141: Implement true global package parameters (response to 20)
Posted by Torben Brosten on 01/31/10 08:18 PM
Nice find, Dave,

I was thinking about permissions with regards to parameters, in the context of sensitive data in ecommerce package for example.

The CONTEXT attribute solves that with the addition of your "none" suggestion.

Collapse
22: Re: TIP #141: Implement true global package parameters (response to 4)
Posted by Emmanuelle Raffenne on 01/31/10 09:04 PM
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
23: Re: TIP #141: Implement true global package parameters (response to 22)
Posted by Don Baccus on 01/31/10 09:18 PM
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! :)

Collapse
24: Re: TIP #141: Implement true global package parameters (response to 23)
Posted by Emmanuelle Raffenne on 02/01/10 01:47 PM
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.