Forum OpenACS Q&A: Response to Enhancing the Installation Process: Automation.
Posted by
Lee McKusick
on 09/04/00 09:15 AM
If I get any more interested in how to automate the OpenACS installation, I will have to substitute deeds and code for words. But I am not a very good programmer, I am mostly an administrator.
I restate the post above. RPM alone isn't flexible enough to make an OpenACS distribution.
OpenACS users will add modules. Somebody may port OpenACS to PerlCGI and Apache. Somebody may migrate back to Oracle.
Some OpenACS users will build large, professional and dedicated systems. Some users will work on a shoestring with four 512 meg hard disks in a DX-100 box in an hospital in a 3rd world country.
On a development side, how can the volunteer keepers of the pristine source cope with the widely variable quality and widely variable dependencies of many users?
I suggest the OpenACS RPM contain a database of OpenACS systems and contributed modules. Plus the RPM will contain conventional tools and documentation.
So OpenACS would put out one RPM. The RPM can actually be upgradable even at a production site, and the only dependency would be for a Postgres database.
This RPM would go to a fixed file location like RPMs must.
This RPM would offer: documentation, tools, contributed tools, a database access front end (a miniOpenACS maybe) and several separtate databases or dumpfiles.
The user would run the database front end to either get a copy of the current OpenACS or run select statements to pull up an alternate system or information about OpenACS variations.
A new user can get started with the basic OpenACS reference distribution. An established system user can go shopping for new modules fitting the constraints present in the established system.
A database supports user contributed growth and evolution of the OpenACS system. The user would run contributed tools on her existing OpenACS system to make a diff of her system for contribution back to the OpenACS contributions database.
A database of OpenACS and contributions supports the idea of building a tool box, building on other people's work, creating a setting where many people around the world contribute to the development of OpenACS to serve many human needs.
A database would change the OpenACS coordinator's problem to figuring out how to clarify the contributions. The coordinators would have a problem of nearly redundant contributions. The coordinators would need to write a new module for OpenACS to marshall contributors into "workgroups". Like bboard, OpenACS would be prospecting for volunteer coordinators to massage contributed files into named and tested and blessed modules.
There could even be a feedback loop: a user starts with a reference system, modifies it, contributes a developmental diff back to OpenACS. Coordinators massage several developmental diffs into a new reference quality module, OpenACS creates for the contributors, a upgrade diff that replaces the developmental diff with the new reference quality code.
Un-normalized view of the system and contributions database:
Filename, author, date, comment(s), statement(s), earliest-ACS version, latest-ACS-version, called-by(), calls(), earliest-database-version, latest-database-version, script-language, earliest-script-version, latest-script-version, table(s), line-number, module-name(s), web-example, author-email, license.
I restate the post above. RPM alone isn't flexible enough to make an OpenACS distribution.
OpenACS users will add modules. Somebody may port OpenACS to PerlCGI and Apache. Somebody may migrate back to Oracle.
Some OpenACS users will build large, professional and dedicated systems. Some users will work on a shoestring with four 512 meg hard disks in a DX-100 box in an hospital in a 3rd world country.
On a development side, how can the volunteer keepers of the pristine source cope with the widely variable quality and widely variable dependencies of many users?
I suggest the OpenACS RPM contain a database of OpenACS systems and contributed modules. Plus the RPM will contain conventional tools and documentation.
So OpenACS would put out one RPM. The RPM can actually be upgradable even at a production site, and the only dependency would be for a Postgres database.
This RPM would go to a fixed file location like RPMs must.
This RPM would offer: documentation, tools, contributed tools, a database access front end (a miniOpenACS maybe) and several separtate databases or dumpfiles.
The user would run the database front end to either get a copy of the current OpenACS or run select statements to pull up an alternate system or information about OpenACS variations.
A new user can get started with the basic OpenACS reference distribution. An established system user can go shopping for new modules fitting the constraints present in the established system.
A database supports user contributed growth and evolution of the OpenACS system. The user would run contributed tools on her existing OpenACS system to make a diff of her system for contribution back to the OpenACS contributions database.
A database of OpenACS and contributions supports the idea of building a tool box, building on other people's work, creating a setting where many people around the world contribute to the development of OpenACS to serve many human needs.
A database would change the OpenACS coordinator's problem to figuring out how to clarify the contributions. The coordinators would have a problem of nearly redundant contributions. The coordinators would need to write a new module for OpenACS to marshall contributors into "workgroups". Like bboard, OpenACS would be prospecting for volunteer coordinators to massage contributed files into named and tested and blessed modules.
There could even be a feedback loop: a user starts with a reference system, modifies it, contributes a developmental diff back to OpenACS. Coordinators massage several developmental diffs into a new reference quality module, OpenACS creates for the contributors, a upgrade diff that replaces the developmental diff with the new reference quality code.
Un-normalized view of the system and contributions database:
Filename, author, date, comment(s), statement(s), earliest-ACS version, latest-ACS-version, called-by(), calls(), earliest-database-version, latest-database-version, script-language, earliest-script-version, latest-script-version, table(s), line-number, module-name(s), web-example, author-email, license.
