I haven't had much chance to work with the acs 4 permission system,
but it seems like there ought to be ways to make it workable
without blindly flattening out the hierarchy and causing polynomial
or exponential sized tables.
In a general way, the permission system seems very nice; you can
assign any object a permission on any other object. When you go
to check a permission between object A and object B, if no explicit permission relation is found, the system
will automatically search up both object's context chains until a permission is found. This is however potentially expensive, either
in time or space, depending on the implementation.
It may be possible to optimize this in various ways, but fundamentally, I think it would be better to look at permissions
as a heavyweight operation, not a lightweight one. Thus, you should
write your code accordingly; don't rely on the system to check
permissions of users and bboard messages, instead explicitly check
they user's group against the message's forum object, and so on.
I think of it like memory allocation in Java or Lisp; just because the evaluator hides the cost of consing up a String, you should not
blindly do that when you can get away with appending to a StringBuffer, etc.
The way that ACS4 tried to sweep this stuff under the rug is indicative of the general problem there now in all their software
development - they have very smart but inexeperienced guys doing
the core architecture, so they don't seem to know how to avoid
the less obvious consequences of adding complex features. While
Philip may have been a little too extreme in the other direction,
leading to overly redundant code, at least the system was nice and
flat and easy to modify, without several layers of abstraction in
the programming language and then in the database.
I think it is becoming clear that it was a mistake to shove this stuff
into the database layer, but I think judicious use of the
permissions system makes sense, if you don't rely on it to
be efficient at a fine grain.
