[Jackrabbit Wiki] Trivial Update of "AccessControl" by angela

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "AccessControl" page has been changed by angela.
http://wiki.apache.org/jackrabbit/AccessControl?action=diff&rev1=9&rev2=10

--------------------------------------------------

  Disadvantages:
   * cannot assign ACLs to non-existent nodes
   * permissions are stored right inside the content (can be cumbersome for backups, etc.)
-  * does not scale with a high number of users (with permissions on a single resource)
  
  == Principal-based ACLs ==
  A different approach for specifying and storing ACLs is to assign certain principals (users or groups) a list of nodes that they are allowed or denied to work on. The nodes will be referenced by paths, and might even include wildcards.
  
- To work with principal-based ACLs, a Jackrabbit-propietary extension to the ACL management API is required, as the JCR 2.0 API is tied to resource-based ACLs at the moment.
+ To work with principal-based ACLs, a Jackrabbit-propietary extension to the ACL management API is required.
  
  Advantages:
   * permissions can be assigned to non-existent nodes
   * permissions are stored separately from the content (good for content replication, backup etc.)
-  * scales better with a high number of users
-  * caching of ACLs is easier, since they naturally are grouped per-principal and JCR sessions are per-principal as well
  
  Disadvantages:
-  * scales not so good with few users and a high number of permissions for each user (however, that is a very seldom use case)
   * additional Jackrabbit API has to be used for setting ACLs
  
  == Repository Configuration ==