Forum OpenACS Development: ACS 4 missing the parameters file

Posted by Henry Minsky on 04/12/01 03:14 AM

One thing I wanted to note for the record is that ACS 4 had
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.

2: Response to ACS 4 missing the parameters file (response to 1)

Posted by Don Baccus on 04/12/01 04:05 AM

That's an excellent point Henry, and yes, I agree with you, especially since you're volunteering to work on it!

3: Response to ACS 4 missing the parameters file (response to 1)

Posted by C. R. Oldham on 07/15/01 02:41 AM

Here's another reason to be able to edit that in a text file.

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?

4: Response to ACS 4 missing the parameters file (response to 1)

Posted by Don Baccus on 07/15/01 05:58 PM

You should probably e-mail Henry directly. I know he originally had hoped to have time to do the bboard port, too, but then his life got taken over by (I think) a Real Life Gig leaving him insufficient time to do so.

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.

5: Response to ACS 4 missing the parameters file (response to 1)

Posted by Henry Minsky on 07/16/01 06:57 AM

Hi I'm around, sorry for being somewhat out if it.

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.

6: Response to ACS 4 missing the parameters file (response to 1)

Posted by Henry Minsky on 07/16/01 07:24 AM


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 help


defpackage_param module_name mount_path param_name value
...
..


so a param file might look like 

defpackage_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?

7: Response to ACS 4 missing the parameters file (response to 1)

Posted by Henry Minsky on 07/16/01 09:14 AM

Well, OK, I am overlooking the fact that some packages are not mounted anyplace. So the file format above might not cover all cases.
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.

8: Response to ACS 4 missing the parameters file (response to 1)

Posted by Don Baccus on 07/16/01 06:25 PM

Regarding XML, I have no problem with you using a Tcl file instead. If we were trying to develop a way to dump an ACS Tcl configuration into (say) an ACS Java installation then XML would make a lot of sense, but we'll only be dealing with the OpenACS Tcl -> OpenACS Tcl case.

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 ...

9: Response to ACS 4 missing the parameters file (response to 1)

Posted by C. R. Oldham on 10/25/01 09:58 PM

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]

instead of

[ad_parameter AllowAdminSQLQueries "" 0]

10: Response to ACS 4 missing the parameters file (response to 1)

Posted by Don Baccus on 10/25/01 10:18 PM

Hey ... that's pretty cool, I didn't realize it still would pull stuff from the init file. Now that I know, I'll just pull it out ... I'm kidding. This should be a big help for you.

I'll try to find time to take a look at the ad_paramter calls you've questioned ...

11: Response to ACS 4 missing the parameters file (response to 1)

Posted by C. R. Oldham on 10/25/01 11:12 PM

Don,

I opened a bug report and created a diff that incorporated my changes. It's bug 1227. Patch has been uploaded.

12: Response to ACS 4 missing the parameters file (response to 1)

Posted by Don Baccus on 10/25/01 11:40 PM

I'll take a look at it - we need to modify the *-oracle.xql and *-postgresql.xql files rather than the *-.tcl file(or in addition too, I guess, in order to keep the sources in alignment). This stuff's gotta run under PG, too!

Thanks for the patch, though ...