[Cosmo-dev] acegi ACL implementation - more thoughts

[Vinubalaji Gopal]

On Tue, 2006-11-21 at 16:07 -0600, Randy Letness wrote:

> I'm confused.  Are we talking about using two persistence apis (one for 
> ACLs using straight jdbc and one for rest of the model using 
> hibernate)?  This might be confusing because ACLs are associated to 
> Items and ACEs to Users right?  Items and Users are managed by 
> hibernate, and ACLs would be managed by some other acegi jdbc 
> framework?  This seems like a bad idea, but I need to look at the acegi 
> stuff closer.

Here is the schema of old acl implementation. The new acl schema will be
different but the basic idea will be the same.
http://www.acegisecurity.org/dbinit.txt

An ObjectIdentity is constructed to secure any domain object and this
ObjectIdentity is based on class name, id, etc. So we will have to
construct an ObjectIdentity based on the Item, ContentItem, etc. 
Check out addPermission at:
https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity/samples/contacts/src/main/java/sample/contact/ContactManagerBackend.java
and
https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity/samples/contacts/src/main/java/sample/contact/ContactDaoSpring.java 

User or Group will be mapped to an Sid.

So ultimately storing anything in the acl's table goes through a mapping
process and it will not be really confusing  if we do this mapping
neatly. 

Yes having two data sources may not be desirable but if that is the best
way to achieve performance we have to go for it. If there are ways in
which we can achieve the same performance using hibernate, we could do
that. The jdbc based implementation also has a default cache
implementation. 

Other thing if we think about clustering, etc and if hibernate has
inbuilt support for that, we could think about hibernate based
implementation at that time or if there are more reasons we could have a
hibernate based implementation now itself.