[Grok-dev] Re: grok.repoze and repoze.who
faassen at startifact.com
Mon May 19 12:07:12 EDT 2008
Santiago Videla wrote:
> On Sat, May 17, 2008 at 2:16 AM, Santiago Videla
> <santiago.videla at gmail.com <mailto:santiago.videla at gmail.com>> wrote:
> > Documentation team (whoever feels called for this), do you want
> > to work with Santiago to help update the tutorial on
> > grok.zope.org <http://grok.zope.org>? (and also the one on
> > repoze.org <http://repoze.org>, by talking to the right people?)
> This will be great. My english it´s a little bit poor, but if you
> can live with that..., me too :)
Now we only need to have the documentation team wake up. I suggest you
start sending mail to Kamon Ayeva or Peter Bengtsson (singling them out
more or less arbitrarily) if they don't chip in themselves. :)
> > Last thing: anybody aware of repoze.who how can be used in
> grok to
> > tackle the authorization issue?
> What authorization issue are you talking about?
> A few days ago, we were talking about user authorization and
> authentication in #grok channel. I understand that the LoginDemo and
> PlainLoginDemo apps are two approach to that, am I right?
To authentication, I'd say; authorization is another area.
> I just read about repoze.who and I know that in TurboGears 2, they
> plan to use it.
> Just asking if it has any meaning to think this on grok, maybe it´s not
We had some discussions about WSGI at the sprint. One thing to consider
is that there is a debate on whether some of these middleware components
are actually clean middleware (as the application won't run properly
without them anymore), and whether this actually should be implemented
as WSGI middleware at all. See this for a discussion:
In Zope of course we have a quite flexible way to do extend applications
already through the Zope Component Architecture, which allows us to plug
things in at many more points than just as WSGI middleware.
We do have a perfectly capable authentication infrastructure in Zope 3
already. repoze.who is, I understand, actually inspired by it. The
problem is that the infrastructure is not documented enough, and there
aren't enough sensible defaults to get started easily. The next task
would be to fix those.
That said, there are of course interesting aspects to approaches like
repoze.who. While it might not be true middleware in some sense, it is
something that is quite loosely coupled to the application, and can be
easily exchanged between frameworks. I think this is partially because
WSGI is a lowest common denominator API that a lot of frameworks alrady
speak, and partially because using it encourages loose coupling between
More information about the Grok-dev