Hi Richard,
I agree that the role system is pretty evil. However, I'm not sure we
should put roles as nodes in the namespace, so maybe you could elaborate
a bit. Where would the user-role association be stored? What difference
would there be when compared to groups? Shouldn't we think about adding
direct role support to the Node class, replacing the inheritance scheme,
i.e. sth. like:
public abstract class Node {
...
Set getRoles()
addRole(String role)
removeRole(String role)
...
}
i.e. a more conventional approach?
Unger Richard wrote:
> Hi!
>
> While there is more traffic on the list: What is the deal with roles in
> slide?
>
> What is the rationale for their implementation as interfaces? In my eyes,
> this has several disadvantages:
>
> 1) It is difficult to create new roles at runtime - a new role requires
> creating and loading a new interface.
> 2) It is difficult to assign a user more than one role - this requires
> creating a new class implementing the interfaces of multiple roles.
> 3) It is impossible to destroy roles without shutting down the virtual
> machine.
>
> Basically it seems very inflexible, because the roles are defined by java
> interfaces. I would propose moving the roles onto the slide filesystem, like
> the users themselves. A new collection /roles contains all the roles that
> can be assigned to users. The roles for each user are set in her properties.
>
> In my eyes this would allow a more classical use of roles in the permissions
> system, where multiple roles can be assigned to a user, new roles can be
> created and removed, and there is more flexibility.
>
> Comments? Should I attempt this?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
