Jeremy, what are your concerns of us just trying it? The only argument remaining against it as far as I can tell is this: "It might be a burden to the development team to tell users how to set up properly, or if there are any issues resulting from it, for us to support." That's mostly it.
So, if that is the case, let my 4-year commit history and forum and email and documentation activity be an indication as to who would actually have to deal with anything that might come up. Isn't that good enough to relieve any possible burden you indicate *might* happen? Plus that if it just doesn't feel right, that we could do the 5 minute change to revert before 1.0? Seriously, this issue could just go away right now. Just bite. You know you wanna :-D On Tue, Jul 15, 2008 at 2:07 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 1:39 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: >> I don't see what's so great about being free of a logging abstraction API >> when our API does tons of logging. > > That can be said about the other wrapper API we use now (caching) or > any other we might use in the future. I didn't hear you make any > arguments to this effect when we wrote our Caching support though - in > fact I think you were the initial author (I can't remember off the top > of my head). > > And although logging is more ubiquitous than caching in the OS world, > that does not change the _principles_ in effect. They are the exact > same. We should be consistent in all areas of our design approach. > That makes more sense to me than "we do this for everything - but, oh, > logging - well, we just ignore that case...". > >> To me, removing this dependency just creates more confusion and obfuscation >> around the right way to set things up for users - > > I disagree - there is a big fat section describing what is required in > the README and it will sure as heck be documented in the quickstart > guide and user manual. > > And I think there would be more confusion and frustration without it: > > Lets say we do use SLF4J without this wrapper API. All we require in > our framework is slf4j-api.jar. When a user downloads jsecurity and > deploys the first time. They'll see errors due to deployment because > they might not have a binding implementation available. Now they have > to go download the binding implementation they want to use. But we > don't include them all in our framework, because we don't need them. > > So, an evaluating user is going to be like "Why won't this just work? > I now have to go to the slf4j.org website just to get this to work?" > What a pain in the ass. > > We could include all binding implementations of slf4j in our > distribution, but that just bloats everything and feels cludgy. > >> creates more confusion because they aren't using a logging API that they're >> used to using. In reality, users *should* use an underlying logging >> framework - > > I disagree - that is entirely up to the end-user. Although some work > needs to be done to enable the following, think of cell phones: > JSecurity should be usable in this environment as well - and we have > nothing preventing this today, other than our packaging - the full > jsecurity.jar would probably be too big to use, but that doesn't mean > we can't split it up some point down the road. > > What if the cell phone environment doesn't have slf4j or doesn't want > to import it to reduce size. This is a perfectly acceptable (and > expected) scenario. There is no reason why we can't support this. It > _would_ be supported automatically if we use my solution. Yet another > use case where low coupling saves the day. > > Heck, what if slf4j or other logging wrapper is just not allowed by > the company? This _does_ happen in real life - in fact, my current > client is one such organization that limits what jars can be in a > project without a formal review process. This happens more often than > you might think, especially in security conscientious and government > organizations. My solution enables these environments as well. > >> so allowing JSecurity to work without one just makes it a) easy >> to set things up badly and b) adds confusion around what a user should do to >> set things up "right". > > This is solved in the quickstart and reference guide. Especially > because we lay out the directions step-by-step, anyone can follow > along. > >> I guess there's a tradeoff in this architecture ideal you have of "zero >> dependencies" vs simplicity and standardization. I'd rather go with the >> simpler, more standard approach that most users and developers understand >> already. Especially since the "zero dependencies" ideal is driven by pure >> "academic" desire, rather than a widespread need across the community. > > When creating a ubiquitous security framework, you *should* think of > accounting for edge-cases rather than just widespread need. > Especially if end-users are already asking for it or discussing it, as > was the case that triggered off this entire discussion. > > Les >
