On 1/25/02 11:19 AM, "Gonzalo A. Diethelm" <[EMAIL PROTECTED]> wrote:
>> You can go all the way with empty interfaces, you can implement >> whatever you want. > > Ok, you want TOTAL flexibility. Yes, sorry if I was beating around the bush there. I would like total flexibility at the top-level. Exercising the complete flexibility may be rare given a default that is itself very flexible but I want the option to be there. We may not even heavily document this feature if we have a default model that allows us to have a standard admin app, and a collection of pluggable tools but if someone is in a bind to integrate some legacy system or just doesn't want to be bothered with the default model then they can go about their merry way. > I fail to see how you plan to USE > such SecurityService from Turbine in a way that allows you to change > the implementation without having to recompile Turbine, but if you > are ok with that, that's fine. I'm fine with that. I believe that if you and Dan design a model that almost everyone can use then that's what will probably get used in the majority of cases. > Moreover, I guess if all we have is one empty interface for SM, you > don't really need anything else from me or Dan D., right? You guys can definitely play around in the rundata-security-changes branch and implement the default you think is a workable overall solution. >> We can have everything we were discussing yesterday in IRC, just push it >> down one level. > > Ok. Out of curiosity, I would still want to know how you plan on > using (calling) the security service from Turbine. I guess we can > leave that for IRC later... (and I hope you are feeling better). We can chat about that in IRC. I think introducing any security model with a combination of a valve, subclassed moduel and/or subclassed rundata would do the trick. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
