On Sat, Mar 29, 2008 at 4:23 PM, mdoudoroff <[EMAIL PROTECTED]> wrote: > Unfortunately, I can confirm that the AuthKit documentation situation > is appalling. I spent hours sifting through the obsolete "Pylons book" > chapters, their comments, the source code, and the cookbook documents > before getting AuthKit running. The enraging thing is that afterwards > I realized that setting up AuthKit is actually quite easy! There's > relatively little to it! Yet the documentation turns it into this > monolithic, impenetrable thing. This is NO WAY to attract new users > (and eventual contributors) to Pylons! Fundamental stuff like this has > to be fundamentally EASY, or people are going to look elsewhere.
We need somebody who has used AuthKit to write the simple HOWTOs that people are asking for. It sounds like you're qualified, if you're willing. The reason documentation is slow is that fewer people build authenticated sites than use SQLAlchemy/Genshi/forms, so there are a fewer number of people qualified to write auth documentation and to compare alternative auth libraries. The two chapters are part of a book that aims to be a complete reference of Pylons programming, scaling to large sites. I guess they don't work as well outside that context. The complete book draft is supposedly going to be finished this week, so hopefully we'll have a copy online soon. The fact that James wrote both AuthKit and the book, and would like to see both as Pylons' standard, yet he responds to email sporadically (sometimes yes, sometimes no, sometimes a month later), has made it difficult to resolve the issues around AuthKit. This leaves the rest of us in a bit of a take-it-as-is-or-use-something-else situation. > It seems to me that AuthKit may have a few warts: > > 1) The "one group per user" limitation seems to be irritating people. > I don't personally care, because all I need are roles, and I can't > help but wonder if the people who are complaining about user groups > really need the groups or if they're just confused about the > distinction because the documentation is such a disaster. Could be. > 2) Some of the authentication plug-ins may be under-developed. Some > people here are saying the OpenID stuff doesn't work very well. I > don't know a thing about it, but I see that OpenID is getting pretty > pervasive, so it will probably be increasingly critical to would-be > Pylons adopters. OpenID is a new and different kind of authentication system, so I don't know if we've figured out the best way to integrate it yet. Feedback from those who use OpenID would be helpful. > 3) The options for how log-in screens are presented with AuthKit seem > too constricted or inelegant for some people. That may be. > I'm just starting to > look into this myself, but I have no opinion, yet. I will say that > it's something that should just happen "out of the box" and it should > be darn easy to customize. > > That several different parties have initiated their own parallel > authentication kits for Pylons while nobody can be bothered to put a > few hours into updating and completing AuthKit's documentation is > really disconcerting. It does not say that Pylons is a flexible > platform with a wealth of options. It says Pylons is a fragmentary, > incomplete, incoherent platform that can only get you part of the way > there. > > I'm a refugee from an old python framework--Webware for Python--that was > rife with derelict components from the get-go. It just looked > terrible. It was embarrassing. There were consequences: the community > waned far more than it waxed. I just got serious about Pylons. I think > it does a lot of things right, apparently with much credit due Ian > Bicking. I apologize for dropping this rant into this thread, but I > want to emphasize how big a problem this is for Pylons. I also started with Webware after being disilusioned with monolithic Zope. But I didn't like its servlet paradigm, borrowed from Java. Or its accessor methods or .camelCase. Webware also named its components *Kit, which makes me wish AuthKit was called something else. Quixote seemed much more streamlined and minimalistic so I made several sites in that. But when WSGI came along I wanted something that was fully WSGI and modular down to the core, and Pylons is the only one of those. Pylons aims to contain the most essential tools but does not make arbitrary choices about everything. So it includes Mako but also documents Genshi. It includes FormEncode/htmlfill/webhelpers but also documents ToscaWidgets and Django newforms. That's because we're not convinced that any of these form libraries are the "best" answer, but FormEncode/WebHelpers are an unobtrusive set of modular tools, so more in keeping with the Pylons philosophy. Pylons had built-in database support but found it couldn't keep up with the libraries, so it dropped that in favor of merely supporting SQLAlchemy in the documentation. Pylons 0.9.7 offers a default SQLAlchemy model as a convenience, but you can take it or leave it. Regarding auth, that has never been seen as a core Pylons responsibility. If you want a framework with a built-in auth library, see TurboGears. Nevertheless we want to support auth in the documentation, either with AuthKit alone or AuthKit plus alternatives. As Pylons has partnered with TurboGears over the past six months, each has focused on its unique strengths. TG chooses a set of batteries for all aspects of web programming. Pylons focuses on a small set of essential tools, yet the documentation also shows how to integrate extra libraries. Generally we choose one library to recommend by default, yet try to show how to use the alternatives too, so users aren't reinventing the wheel from scratch. That has been one of my personal goals, which is why I've worled so much on the sQLAlchemy documentation even though SQLAlchemy is not a Pylons dependency. To answer another question in this thread, repoze is a set of WSGI-compatible libraries spun off from Zope. It's the most exciting contribution from Zope since ZODB, because it allows Zope products like Plone and other WSGI apps to be mixed in the same site. However, it's all brand new so it hasn't been fully evaluated which parts are most useful in Pylons apps. Again, we need feedback from people who try repoze.who. AuthKit was written for Pylons and uses the Pylons configuration system. Nobody has yet evaluated how to integrate repoze.who into Pylons' configuration, or whether it's worth it. I've heard praise for AuthKit's authorization but not for its authentication. Maybe the two will be split someday; that was part of my hope for the wiki page, that we'd pin down exactly what we need in an authentication system, and then make it easier for AuthKit to interoperate with other compliant systems. And simultaneously fill the gaps in AuthKit's documeentation and features to make it suitable as Pylons' first recommendation, since it is the only one specifically built for Pylons. Nobody has put any feedback on the wiki page yet. :( I renamed it so here's the current URL: http://wiki.pylonshq.com/pages/viewpage.action?pageId=11698714 -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
