Hi developers,
I agree with Richard. I don't use roles because they are not
flexible. I hope I solve my problems by using groups. At first
sight I'd think Christopher's solution should be enough.
Andreas
On 4 Oct 2002 at 14:23, Christopher Lenz wrote:
> 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
