Also I'd still like to flatten out the number of defined permissions. If we didn't have 20 different "foo_read" privileges performance would be better. Currently the more packages you add the poorer the permissions system performs simply because of all these "foo_read", "foo_write" and "foo_admin" permissions all of which are children of the global "read", "write" and "admin" perms which adds to the denormalized hierarchy maps.
Don, the "foo_admin", etc., kind of privileges obviously exist in some numbers in the current toolkit ... I am curious if you (or someone else) could explain why they are there in the first place? What purpose do they serve?
From a practical administrative viewpoint, it is of course important to be able to delegate the administrative responsibility over certain packages in order to relieve the SWA(s). But that, in itself, doesn't mean you have to create a specific "foo_admin" privilege for every such package - giving a person the normal "admin" privilege on a package instance would suffice, right?.
As far as I can tell, the only benefit from using "foo_admin" to using "admin" would be that you may give someone "foo_admin" (admin restricted to instances of package "foo") on a whole subsite or the entire site, and not have to hand out the same permissions again when the you (the SWA) mount new instances of package "foo".
I presume the use of the "foo_blah" type of privileges may have better justification than that, though, if it is to be worth the performance cost.
