On Mon, Nov 24, 2008 at 10:09 PM, Dalius Dobravolskas
<[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> On Mon, Nov 24, 2008 at 11:56 PM, Florent Aide <[EMAIL PROTECTED]> wrote:
>> TurboGears 2 team has chosen repoze.who to implement authentication
>> and has spawned repoze.what to implement authorization.
> That's their choice but that's not argument. What was reasoning behind that?
>
>> I feel that
>> repoze.{*} is quickly becoming a convergence point between our
>> communities (zope, pylons, tg, and wsgi minded framework out there).
> Really? repoze.who is inspired by zope but not used by zope!!! TG2 is
> basically the same pylons (as Cream for Vim). And finally I don't know
> other pure WSGI framework out there except Pylons. repoze.bfg says
> they rely on WSGI but I don't feel it this way. Django is not using
> repoze.who.
>
> You shouldn't trust your feelings sometimes because there is no real
> convergence point here. I personally see only Zope complexity added to
> Pylons. Maybe some people can't live without that :-)
>
> I will repeat my question: what additional value is created by
> repoze.who what WSGI can't do?repoze.who *is* WSGI. :) And theoretically it has a lot going for it, being a "small, sharp tool" (i.e., it tries to do only one thing, and does it flexibly so it can be used in a wide variety of circumstances, like Beaker). So I can eventually see it gaining wider adoption among frameworks (some of which have not been written yet). The complaint that it's not used by Zope is ridiculous, since it was derived from Zope. (One could ask why Zope wasn't made modular in the first place, but that would be churlish in light of Zope's spinoff contributions to the Python-web world, of which repoze.who and ZODB and Plone are just three examples.) The reason repoze.who hasn't made greater gains, I think, is because it's still more complicated than many people would like. I look at the size of configurations in the tutorials and think, "That's more than I'd rather do; I can write something myself in the time it takes to learn it." Beaker needs just three little lines in development.ini, and most people find the defaults to be adequate. That's not true of auth, which needs at least some kind of user database and other application-specific decisions. That may just be an intrinsic problem of any application-independent authentication library: AuthKit has similar complexity. The question isn't really "What can repoze.who do that some other WSGI middleware can't?", but the fact that repoze.who is already written and has a growing number of plugins. That is evidence of some measure of stability and flexibility. The configuration is not dead simple but it's competitive with the alternatives. Repoze is certainly becoming *a* convergence point, as is Paste and WebOb and Beaker and SQLAlchemy. It may not be *the* convergence point due partly to Zopish complexity and because Paste had a several-year head start, but it certainly has potential, and it sounds like repoze.what will fill one of its main gaps. > The main mistake makes everyone when they implement authorization plugin/middleware, they think that everyone builds social networks or simple sites where you have users in groups with roles. In real world that does not work sometimes. "Groups with roles" goes a long way toward solving the problems of many complex sites. What other model is there that's more applicable? What are examples of sites where this kind of model breaks down? Perhaps a common *implementation* can't be imposed on most applications, but the *idea* can often be. -- 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 -~----------~----~----~----~------~----~------~--~---
