Re: Best practices for persisting (serializing) ACLs

Darby Felton wrote:
> 
> Are there other more specific aspects of ACL storage you wish to
> address? At this high-level of discussion it is difficult for me to
> provide clear and helpful answers.

There are two things in particular I would like to get some feedback on:

1) What are others doing to persist ACL data, and why did they choose that
particular method?
2) For those that are serializing the entire ACL, how do they handle
multi-user systems where multiple simultaneous edits to the ACL could happen
at one time?

For a concrete example of 2), consider a CMS for a school.  There may well
be multiple admins to this system -- how about Jim and Joe?  Jim is making a
change to the ACLs on data in the Physics lab, at the same time as Joe is
making a chance to the ACLs for who can upload pictures to the Art
departments photography page.  What happens?  If the ACL is just a blob that
gets pulled out of the database, manipulated, and then saved, then we
basically have the same situation with multiple people opening the same
file, making different edits, and saving the file back to disk -- whoever
saved first, will lose their changes, when the second person saves.

For this reason, I prefer ACLs that have a greater level of granularity in
the way they are persisted.  This allows you to edit one small portion of
the ACL without requiring the entire ACL system to be locked from changes.

  -Josh
-- 
View this message in context: 
http://www.nabble.com/Best-practices-for-persisting-%28serializing%29-ACLs-tf4691647s16154.html#a13428091
Sent from the Zend Auth mailing list archive at Nabble.com.