jakarta-slide-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unger Richard <run...@camino.at>
Subject AW: AW: [RootRoleImpl]
Date Fri, 08 Nov 2002 15:56:41 GMT

Thanks for the feedback!!! I've inserted my comments in the text...


> -----Urspr√ľngliche Nachricht-----
> Von: Christopher Lenz [mailto:cmlenz@gmx.de]
> Gesendet: Freitag, 08. November 2002 16:24
> An: Slide Developers Mailing List
> Betreff: Re: AW: [RootRoleImpl]
> 
> 
> Unger Richard wrote:
>  > Hi!
>  >
>  > This is exactly what I have been working on. The new code 
> is almost ready
>  > for CVS.
>  >
>  > Basically what I have implemented is a new Helper interface, the
>  > SlideUserDatabase, which provides an API for creating, loading, 
> saving and
>  > deleting slide users, groups and roles.
> 
> Not very fond of the name. How about putting the helper in 
> the existing
> authentification package, and, staying consistent with other helpers
> naming, call it Authentification?
>

Fair enough, I can change this, the name and package should probably be set
before CVS committing...
Moving to package authenticate with name Authenticate seems more in keeping
with the other helpers, as you say.
 
>  > In implementing this I have had to make some fairly deep changes. 
> Roles are
>  > no longer stored 'as the class' but in the class. The 
> different Node 
> classes
>  > for the slide structure now represent the node type, for example 
> SubjectNode
>  > for users, GroupNode for groups, LinkNode for links, etc. 
> All Nodes 
> inherit
>  > from ObjectNode, which implements the RoleContainer 
> interface. ObjectNode
> 
> I don't really like the name RoleContainer, although I can't 
> think of a
> better name (Rolable :-D ).
> 
> Some brain storming: Why have an interface at all? If roles are a
> user-specific concept, why not just put the relevant stuff in
> SubjectNode directly?
> 

Well, the idea on my part was to keep compatibility with the slide concept
that every node in the stucture is associated with a role. Thus it is still
possible to get a SlideToken for an arbitrary node on the filesystem, and
use it for access. It makes it possible, for example, to have a
WorkflowNode, with roles, or something like that. I have to admit I never
fully understood the necesity for every node to have a role, but I went with
it.

>  > itself contains only the NOBODY role, and does not permit 
> adding roles or
>  > changing the role. Other node types can override the RoleContainer 
> methods
>  > to allow multiple roles and changing the roles, as 
> SubjectNode (for 
> users)
>  > does.
> 
> Isn't SubjectNode also used for non-user nodes? My memory may 
> be failing
> on me, but I thought SubjectNode is just a non-abstract 
> ObjectNode that
> is instantiated in various places...
> 

Yes, but the new node type for this would be DefaultNode in my
implementation, which is simply a non-abstract version of ObjectNode (and
thus has the NOBODY role only).

> I agree with you that SubjectNode *should* be the node type for users
> (actors) and only users.
> 

Exactly.

> And while I really agree with your motivation for all this 
> refactoring,
> I think this is going to cause *huge* changes to the kernel. Geeze I
> wish we had unit tests :-(   Lacking those, such changes are pretty
> dangerous.
> 

Hmmm... I have finished my implementation of the SlideStoreUserDatabase (ok,
SlideStoreAuthenticateImpl :) ), and have all the ObjectNodes and subclasses
written. Next I have to modify the Security helper to use the new concept of
roles.

Other than that, I do not see such problematic changes. Wherever roles were
used a few changes will be necessary, uses of SubjectNode have to be changed
to DefaultNode, but I think these changes, though affecting a lot of the
kernel, are mostly cosmetic. I don't think the logic of the methods needs to
change, and so I don't think it is so bad... I will be attempting to do this
early next week, and will let you all know how it goes...

Richie

PS: Who is using Java 1.4, Java 1.3, or Java 1.2.2? Basically, I guess my
question is can Slide 2.0 be designed for Java 1.4, or do we have to support
1.3 or (gasp) 1.2.2? Basically, I am using very little 1.4 functionality
(regular expressions), but I use the new collection classes extensively
HashMap, Iterator, ArrayList etc, instead of Hashtable, Enumeration,
Vector... Is this a problem?

PPS: Synchronization: I wanted some advice about the transaction stuff,
without digging in the code... Does using the transaction.begin() and end()
methods synchronize different threads on the transaction, or should I
synchronize access to the userdatabase explicitly myself? Is there anything
to watch out for when using the transaction stuff, or is it really as simple
as just calls to begin() and end()?




> -chris
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:slide-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:slide-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:slide-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:slide-dev-help@jakarta.apache.org>


Mime
View raw message