Forum OpenACS Development: ACS 4 missing the parameters file
one annoying drawback that I think we can easily correct. ACS4
did away with the /parameters/yourhost.tcl file which contained
module config parameters, and tried to put them into the
database, maintained through a web interface.
But the problem was no code to produce a backing file format ever
written, so the
state of your site couldn't be easily saved out to a file. If you
needed to reinstall a copy of your site, there was no way to
get all the module parameter values easily in one place.
There were basically two things that it would useful to save: The
mount points and type of mounted package instances, and the parameter
values for each instance.
I would be willing to help write such a tool. I would personally
rather edit parameters in emacs than using a web interface. And having
this info in a file makes it much easier to install a new "clean" site
with the same configuration as another.
In our shop, we have several developers working on ACS-backed stuff. We needed a way for each of them to be able to work on an ACS instance, but we didn't want to have to duplicate the ACS schema for each developer--it would be too hard for the less-experienced developers to handle that, unexpected breakage from schema changes would appear much later in testing, etc. So we wrote scripts that would let us embed "metavariables" in parameter.ini and nsd.tcl. Then when a developer starts up his/her instance of AOLserver, instance-specific values for variables would be substituted in.
This has worked fantastically for us.
ACS 4 broke it completely.
There was no way to offer the "many developers-one schema" version of stuff anymore. I even looked to see if we could add a field to the parameters table so we could designate a different parameter "scope", or create a "view" to the parameters table that would be specific to a particular user, but no dice.
Henry, if you need more specifics on what we did, let me know. How is this coming, BTW?
So it goes - I've had to cut back my efforts on OpenACS 4.x because of a client gig, myself.
Anyway, he's not been hanging out here recently, at least on a regular basis, thus the suggestion that you e-mail him directly.
I'd like to make some progress on this. I have two alternative
approaches, not sure which is best:
1) store the param data as a .tcl script, like we do now with the
tcl server init file.
2) store the param data as some XML format
I am leaning towards using a .tcl file for saving the package params. I am getting somewhat wary of overusing XML as a format for human configurable or readable persistent storage of things. I think the main use for using XML is that it is an easy file format to exchange between heterogenous systems. However, if the param files will only
be read and written from OpenACS, then I don't see the advantage. Tcl
is a powerful macro language, so we can write a file format that
can be evaluated to load it. The advantage is that you can then
put procedures in the file. This is very powerful, we use it in the example
OpenACS init file that is distributed with the system, and it is a convenient advantage to be able to use variables, function calls etc.
in the param file.
I was turned off by the "ant" java makefile tool file format that Arsdigita started using, because it tries to use XML as first a declarative language, then a programming language, and it is in my opinion somewhat harder to use that bad old "make" syntax, which was bad enough.
Anyway, if anyone has any strong opinions about that, please speak up.
1) the mount points of modules 2) for each package instance, the values of all the parameters I'm thinking a file format like this, with some tcl functions to helpdefpackage_param module_name mount_path param_name value ... ..so a param file might look likedefpackage_param "bboard" "/bboard" "moderated_p" "t"You could just fill a file with these. The loader would check if the named module is mounted at the described path. If not, it would instantiate a new package instance. very simple.. too simple?
In fact, I think it is the case that any packages which are not mounted also happen to be singleton packages, in which case we can
uniquely identify them by their package key. But depending on that to always be true
might not be smart.
So how about this then. We have a defpackage_param function which
takes an optional package instance id as an argument.
This will uniquely identify a package instance. If you go to reload the
params file and the specified package instance is not found, the loader could go ahead and instantiate a new instance, and keep a little mapping table in memory of the old instance id to the new one. Then when further parameter defs are found in the file, it would set those parameters on the new package instance.
That way we would cover the case where you've blown away your database, and just want to reconstruct the system to where it was before, in terms of mounted or instantiated packages and their parameters.
Your last post sounds good to me (as far as the approach and what it gets us). A lot of people will be glad to have this ...
There haven't been any posts to this thread for a while. I started poking at this again today. I ran into the same problem that Henry did--the fact that a package_id can vary from installation to installation.
Then I discovered that ad_parameter will still look at a parameter file, even though it's deprecated. So this solves about 80% of my problem (how to set some systemwide parameters outside the parameters table so they can be different for us depending on who is running the aolserver instance). Joy!
When doing the research on this, I realized that lots of ad_parameter calls don't include a package_key. I think all the ones that don't are pulling parameters for the acs-kernel package_key. Shouldn't those calls say things like
[ad_parameter AllowAdminSQLQueries acs-kernel 0]
[ad_parameter AllowAdminSQLQueries "" 0]
I'll try to find time to take a look at the ad_paramter calls you've questioned ...
I opened a bug report and created a diff that incorporated my changes. It's bug 1227. Patch has been uploaded.
Thanks for the patch, though ...