Re: Auth_Groups and Auth_Permissions

David Costa wrote:

I see you point but, once again sorry if I am too upfront, I don't see something like "Auth_Permissions will be a package designed to allow basic permission checking (true/false will probably be the only form supported, unless there is huge demand for more)," true/false only permission package to provide any substantial benefit to PEAR users.

I have been truely amazed at the lack of imagination on the PEAR dev list lately. PEAR developers are not exactly breaking new ground in the world of web development (let alone the broader scope of software development), yet the members of this list seem really quick to shoot something down if after reading one email they cannot see the benefit. David, please don't take this as an attack on you. This email is just an imputus to speak up about the growing concern I have had.

If you are looking for such a system (true/false only) and you will code from scratch the rest, you probably would code everything from scratch. On the other hand, whomever is looking for a more structured (see Auth source code, I don't see any overhead there...if you don't want the login then you probably don't want an Auth system library either).

I could probably throw out several different globally useful schemes, and heaven forbid we have a way to manage groups and permissions that uses a driver system (factory or singleton) to allow for greater flexibility.

To my the current existing Auth packages on pear (Auth, Liveuser) do cover this category very well. Of course this is just my opinion but as you are just at a draft level, I wouldn't encourage new packages in this direction.

This just stifles progression. I would encourage developers to solve any problem they have in a way that allows others to use their code. PEAR doesn't accept packages based on the initial idea and to discourage participation is ludicrous. My personal take on the pear-dev community these days is that there are too many egos and quick tounges. Maybe there should be less time spent voicing an oppinion on every damn email and more time coding, deploying, scaling, and supporting real-world apps. Maybe this would help there to be a little more immagination. Respectfully, -Jackson