Forum OpenACS Q&A: RFP: Site-level vs. Instance-level Package Parameters

1: RFP: Site-level vs. Instance-level Package Parameters

Posted by Nima Mazloumi on 06/23/04 07:51 PM

Hi all,

what do you think about introducing site-level and instance-level package parameters. Looking at some packages I found out that there are path informations that are only needed on site-level while there are other parameters that make sense of instance-level.

This way we could even allow site-admins to make site-wide settings while package admins/users would only see those parameters that are relevant for their instance.

An example is file-storage, while

- ArchiveCommand
- ArchiveExtension
- UnzipBinary
- StoreFilesInDatabaseP

look like site-level settings to me,

- GeneralCommentsP
- ShowAdministerPermissionsLinkP
- MaximumFileSize

could be on instance-level. Important now is that even instance-level parameters should be conrolled on by the site-admin. So we would need an intelligent way to allow changes on instance-level and inheritance. This way a site-admin could decide not to make MaximumFileSize a parameter that is set on instance level but allowing GeneralCommentsP to be configurable on instance level.

What do you think?

2: Re: RFP: Site-level vs. Instance-level Package Parameters (response to 1)

Posted by Malte Sussdorff on 06/23/04 11:18 PM

Well, it all boils down to having site-level parameters that can be overridden by instance level ones.

To achieve this I'd suggest to add a parameter setting on the package information in the APM. At the moment, the only actions are "edit" and "delete", but we could add a default value there.

Each package instance then would have these parameters as default values and they can be overridden manually. As a matter of fact, the default value will only work for new instances of the package, not for old ones (otherwise you get into trouble differentiating, if a change in the default value is actually what the current instance owner wants).

I'd not use site level parameters per se, as you should not decrease the number of control a (subsite) admin has over each instance of a package.

3: Re: RFP: Site-level vs. Instance-level Package Parameters (response to 1)

Posted by Rocael Hernández Rizzardini on 06/23/04 11:49 PM

Site-level param change can be achieved in a service package, and Instance-level with application packages, so everything depends where you store your params.
For instance, we wanted to have some params for all the /dotlrn (and the instances below it), so, instead of putting them into dotlrn package (which can have multiple instances), we decided to put into dotlrn-portlet, which is a service, then, if we change their values, all the applications that use this service will have that change reflected and in our case, it made a lot of sense to put the params in the portlet.

4: Re: RFP: Site-level vs. Instance-level Package Parameters (response to 3)

Posted by Jeff Davis on 06/24/04 12:03 AM

Malte: a lot of the things that we want to make "site params" are things that really should not be changed per instance (executables or paths are a good example -- allowing package admins to change these can be a security hole not to mention generally not sensible things to do).

And Roc is right that if you set up a service you can provide sitewide vars that way and the ui package which uses the service can hold the per instance variables. Unfortunately there are an awful lot of params already we want to change to be sitewide and I would hate to have to create 20 or 30 service packages to accomplish that.