On Tue, Nov 25, 2008 at 2:44 AM, Dalius Dobravolskas <[EMAIL PROTECTED]> wrote: > > Hello, > >>> I will repeat my question: what additional value is created by >>> repoze.who what WSGI can't do? >> >> repoze.who *is* WSGI. :) > Actually it is more. It is WSGI (layer programming?) + Zope (component > programming). I just don't get why mix that? Why WSGI is not enough?
By "component programming" you mean the fact that it has plugins? > >> 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. > I'm not complaining. I'm just saying that it is not convergence point. > Well it is convergence point for WSGI and Component programming, but > not for python web frameworks. > >> The reason repoze.who hasn't made greater gains, I think, is because >> it's still more complicated than many people would like. > More or less it is OK. As you said yourself AuthKit has the same > problem. E.g. repoze.who and AuthKit follows the same pattern on form > authentication (cookie plugin + form plugin) while they can use > session instead of cookie. repoze.who wins against AuthKit only > because it does not try to do authorization. That's not important in > our discussion. > >> 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. > AuthKit is written as well. Has plugins as well. I have demonstrated > that you don't need plugins and can write separate middlewares for > that. So by "component programming" you mean plugins? And that's your main complaint against repoze.who? If separate middlewares can do the same job as plugins only better, by all means use them. Pylons used to use Buffet for templating, which had entry-point based plugins. It switched to a much simpler system by providing a few engine-specific render functions and instructions for making your own renderer. That was a significant improvement. If somebody wants to make a library of small middlewares that encompass repoze.who's functionality, by all means go for it. But the question will become, how easy is it to switch from one authentication method to another? Will the middlewares all have a consistent configuration or will they start to diverge? What if you need to combine multiple authentication schemes in the same site? This consistency and combinability is what make plugin systems so attractive: they all have to adhere to the parent's API, and they are built to interoperate. -- 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 -~----------~----~----~----~------~----~------~--~---
