Forum OpenACS Development: Package Parameters, Site Configuration, and /admin

ACS Classic had the ad.ini system to configure various pieces of your
system.  It also had /admin pages to configure other pieces of your
system.  The ad.ini was obscure and not well documented.

In adACS 4.0, the ad.ini got migrated into the kernel parameter setup
of the site map tool (or something like that.)  This was pretty
neat.  No more fumbling around for that ad.ini file and the
parameters now a oh, just a wee bit of documentation and UI support.

But it was controversial: some designers didn't want this simple
package parameter system to BECOME the /admin pages, and yet,
clearly, this was an easy and wonderful first step for package
implementers.  And, as admin pages go, there were in a central
location too, instead of being tossed hither and to in the user pages
as the aD designers suggested was the proper way to create aDACS 4
admin pages.

What is the OpenACS /admin approach?

I would like to see the site map package parameter tool expanded so
that package parameters can have various typing descriptions (much
like ad_page_contract uses) that the site map system can use to
determine if a parameter has been entered correctly.

I would like to see the site map package parameter tool designed to
work well with whatever admin abilities a package has.

I would like to see the data model for package parameters modified:
parameter names should be unique within a package section, not unique
for an entire package.  Consider the adACS 4 kernel: the request
processor has a debugp parameter.  The security handler must then
have a LogSecDebugP parameter.  Can't we all just get along?

On the technical level, plug-ins would probably be just fine, especially as far as data types go.

I think I'm also looking for more of a architectural decision.  As I mentioned in adACS 4, in various bboard messages (maybe private emails) the designers expressed that they really didn't want the site map/package parameters to become the replacement of /admin.  So in some sense, if you folks agree, the idea would be make some sort of counter statement, that in OpenACS 4, the site-map/package parameter system does have a role to play in the /admin of a site or package.

Getting back to technical requirements....  Plugins would fill one need, which is the ability to create validating filters.  Especially plugins along the lines of how we can expand ad_page_contract's filtering/validating capabilities.  A suggested approach might be to include in the data model of a parameter the name of a tcl proc that can validate it.  So I can ensure early on in the site-map system that things that claim to be dates really are dates, or urls are urls, etc.  (At a glance, borrowing ad_page_contract's capabilities would do 90% of the job.)

There is more to /admin of a site then that, and that's why I can agree that the aDACS developers have a valid point.  /admin of a site or package includes the things that the site-map can't have (at this point) such as the ability to delete/modify package objects, or spam users, or all that other stuff.

So maybe there could be more of a /admin plugin built for the site-map system.  Perhaps each package can specify a relative url where /adminning takes place and the site map system can in return publish an API to determine where package parameter information takes place.  The site-map parameter entry pages can then offer that link back to the /admin of the package (and vice-versa)

This simple mechanism would allow developers to quickly use the site-map during the early days of package development as /admin and then reuse that work later on when a more fully function /admin for the package is developed.  (Because I still think there's a lot to be said for having the parameters of a package instance all be in one place, fully documented, and strongly specified (typed, constrained, and validated.))

Plugins for other functionality would be good, but I think the above would make a good first step.  I would like to see standardized /admin capabilities suggested perhaps with support from the underlying ACS substrates.  For instance, I would like to see an packages /admin better support export/purge-or-compress-in-place/import of data, or search for package specific objects (a QBE interface).