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