Hi! I really need to get the names sorted out before I can continue working...
I like the name Authenticate and SlideStoreAuthenticateImpl . I think it fits well with the rest of the helper class model. I also do not think that this will dilute the separation between authentication and authorization, as you seem to fear. All things concerning permissions and checking thereof will remain in the Security Helper. Only the storage of the users, roles and groups is handled by the authenticate helper, which makes some kind of sense. As for RoleContainer, I really have been trying, but I can't seem to come up with a better name for it. The name has to capture the idea, of course, that this is an object to which roles can be assigned. RoleAssignee has been the closest alternative I have come up with, but that does not seem better. So, unless I receive a better suggestion for the above, I will proceed with this nomenclature. Let me know, esp. Michael, as you seem to be very opposed to 'Authenticate'. Richie > -----Urspr�ngliche Nachricht----- > Von: Unger Richard [mailto:runger@;camino.at] > Gesendet: Dienstag, 12. November 2002 13:22 > An: 'Slide Developers Mailing List' > Betreff: AW: AW: [RootRoleImpl] > > > Hi There! > > A question: what is/was the purpose of the autocreateusers > setting? Is this > necessary? Does anyone use this? The current implmentation I > have does not > do this, but if it is important it is trivial to add it. It > just seems to me > that this autocreation of users is a bad idea... Does anyone use it? > > Richie > > > > -----Urspr�ngliche Nachricht----- > > Von: Christopher Lenz [mailto:cmlenz@;gmx.de] > > Gesendet: Dienstag, 12. November 2002 11:18 > > An: Slide Developers Mailing List > > Betreff: Re: AW: [RootRoleImpl] > > > > > > Michael Smith wrote: > > > Christopher Lenz wrote: > > > > > >>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? > > > > > > > > > This would be a really, really (REALLY!) bad name. The > roles are NOT > > > used for authentication, they're for authorization - > > distinct concepts > > > that must be kept seperate. > > > > Yeah, you're right. I just don't like the name "UserDatabase"... it > > would probably generate confusion with regards to the "Store" > > terminology used in Slide. > > > > Richard, I think it would be good if you could split your > > proposal into > > phases that can be attacked incrementally. For example, if the > > UserDatabase is truly a "Helper", it shouldn't be necessary > > to put it in > > from the beginning... > > > > Also, if the proposal is affecting as many classes as you've > > listed in > > your other mail, splitting into smaller implementation > phases will be > > utterly necessary... as it stands you'll need a committer to > > "sponsor" > > your proposal, at least in the beginning. Thus, the > > individual changes > > must be as limited as possible. > > > > -- > > Christopher Lenz > > /=/ cmlenz at gmx.de > > > > > > -- > > 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> > -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
