On 2/7/02 8:55 PM, "Eric Dobbs" <[EMAIL PROTECTED]> wrote:
> Hi All. > > First off, I think the original misunderstanding is > mine. But, this thread has cleared up a bit of my > confusion. > > Because it seems like my contributions are holding up > the merge for RunData, I've moved my stuff into > proposals/eric/security folder. You're not holding up anything, I'm still futzing around and I can work around anything. No worries. > I have also moved > Gonzalo's stuff back inside o.a.t.security.turbine. > The only thing in o.a.t.security is the empty > SecurityManager interface. > > This might go without saying, but just in case ... > Although I've moved my stuff into proposals and left > Gonzalo's in the src tree, I have not given up on > evangelizing some aspects of the JAAS design. 8^) > It seems I'm outnumbered in this conversation, but I > haven't given up yet. 8^) > > Kurt, hopefully moving my stuff into proposals > addresses your concern about littering the package > namespace -- it's only in the proposals directory and > not among the src tree. > > Jason, will that let you proceed with your RunData > work? I've still been working on it, you're not interfering with anything I'm doing I just wanted the branch to compile. > > About the interfaces in o.a.t.security: > > I originally pushed the interfaces into this package in > an effort to follow the model Jason set in o.a.turbine: > put the public interfaces at the base of the package > tree where developers can easily identify the public > interface. I think I see now why that's not what you > had in mind for the security stuff (more on that > below). > > > Empty interfaces: > > I was confused about the idea of empty interfaces. But > if I understand the thinking now, the idea is to have > ONE empty interface for the SecurityManager. This interface may extend some of the basic lifecycle interfaces but that's about it. > Everthing > else would be hidden behind implementations of > SecurityManager. That makes much more sense than the > whole mess of empty interfaces I had created. Also, > with this in mind, I agree that SecurityManager is > better than Policy because it follows the naming > conventions in Turbine. I can keep using Policy in my > proposed implementation but hide it behind > SecurityManager. 8^) > > > Would it make sense to put the empty SecurityManager > interface into o.a.turbine, and put the specific > implementations inside o.a.t.security? Another way to > ask this question: First, am I correct about the goal > of putting the public api in o.a.turbine? Second, > should the empty SecurityManager interface go there > too? I'd like to think about that one before merging the branch into the trunk. I was toying with the idea of putting the security stuff in a separate src/security directory but I'm not sure yet just to keep the core source small and comprehensible. Not sure about the packaging yet either. > -Eric > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
