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

Collapse
Posted by Torben Brosten on
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
Posted by Don Baccus on
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
Posted by Torben Brosten on
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
Posted by Don Baccus on
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
Posted by Torben Brosten on
I mean as a sitewide admin, nondeveloper, who wants to see or change the global parameter value.
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
Posted by Torben Brosten on
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
Posted by Dave Bauer on
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
Posted by Don Baccus on
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!

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
Posted by Nathan Lunt on
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
Posted by Dave Bauer on
Previous TIP about parameter scope
https://openacs.org/forums/message-view?message_id=271910

Oops it was still in my clipboard!

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.