Forum OpenACS Development: Response to Permissions Performance

Collapse
Posted by Barry Books on
I'll just throw out some random thoughts and observations about acs_permissions.

It's really great to have a general way to get permissions on any object. It sucks you can't do it in a where clause. It's unfortunate that the more objects you have the slower it gets.

Some thoughts on how to fix this.

acs_permssion_p should work on any object but not all objects need to store permission information. If acs_object_types where objects you could set permissions on object types. This would allow grouping in the same way the context_id allows grouping. For example create a private_bboard object and make its supertype bboard. Then give a group read access to private_bboard and presto, 1 object in the permission table controls a whole group of objects. Same for attributes, give admin rights to make_live attribute and only admins can change it.

I also think context_id and inherit should be in a different table than acs_objects. If you want to set explicit permissions on the object put a row in the table. Permissions then become like friends in C++. Perhaps add a flag to objects that says if the creator has admin rights. While all this is kinda kludgy it preserves the permission_p model with less object_id in the tables. I think the permission model is scaleable to around 1 million objects on a dual processor box. Depending on how you look at it that's either a lot or hardly any. If every bboard post need permissions you've got a problem. If every forum need permissions that's not so bad.