"If you do the "object type proxy object" and grant permissions on that, then you'd be granting the permission site-wide, which, to me, doesn't really cut it -- I want to be able to host multiple separate sites on one instance/DB for ease of maintenance.
I do see that your proposal works with the existing permissions system, whereas mine proposes to make a change to that existing system to fulfill a requirement, which has surfaced time and again."
Well ... first off Dave's original post talked about "site-wide" as meaning "an entire OpenACS installation", and the object type proxy object approach does indeed meet this need.
Your comment ... well, subsites were designed to be SUBsites, not to implement what in essence are a bunch of entirely different sites within one OpenACS installation. I realize a fair number of people want to use the subsite mechanism to implement a set of unrelated sites, personally I question whether or not it's worth the bother. Pushing subsites into a space where they meet that need involves a lot more than some of the permissions issues that are being discussed here.
And I'm very dubious about suggestions that we make the permissions system more complex. If changes can be made that work with the existing datamodel that's one thing, as I can see how to continue to incrementally improve the performance without much trouble. Since I plan on moving context_id out of the object table, multiple hierarchies can also be implemented without much pain if this were to prove useful (and it probably would to do some of the stuff we're discussing, now that I've thought about it more ... Tom may be right, as much as the additional complexity bugs me).
But changes in the design adding additional functionality that require a fundamental change in the datamodel are likely to work against scalability - and permissions scalability is still an issue in OpenACS, let's face it.
