On Tue, Jan 6, 2009 at 3:10 PM, Chris McDonough <chr...@plope.com> wrote:
> Jorge Vargas wrote:
>> On Tue, Jan 6, 2009 at 1:51 PM, Gustavo Narea <m...@gustavonarea.net> wrote:
>>> Hello, everybody.
>>> I've already started the development of the next major release of 
>>> repoze.what
>>> (initially labeled as v1.5), v2.0, and I wanted to let you know about my 
>>> plans
>>> and also get feedback from you.
>>> First of all, please keep in mind that repoze.what's goal is to support 
>>> common
>>> authorization patterns out-of-the-box, but *never* have a default/preferred
>>> one.
>>> The enhancements I have in mind are:
>>> repoze.who independence
>>> =======================
>>> Many people have requested this, but repoze.what v1 is the successor of
>>> tgext.authorization (former tg.ext.repoze.who; an authorization and
>>> authentication framework), whose dependence on repoze.who was high and when
>>> development started such a featured was not requested... so it was late to
>>> introduce it in v1.
>>> Plus, initially I wanted to take advantage of repoze.who's plugins 
>>> (specially,
>>> mdproviders and challengers) to inject some functionality in the future, but
>>> now I realize that it's best for repoze.what to have its own middleware.
>>> So, authorization patterns that rely on the user's identity (such as the
>>> groups/permissions-based one) will use REMOTE_USER or a custom key in the
>>> environ to get the authenticated user's Id.
>> This is the only bit that bothers me. Could you express why repoze.who
>> is "bad"? which is the alternative? does this means repoze.what will
>> grow it's own repoze.who-like layer? When people "request this" which
>> authentication layer are they favoring, their own little thing? or
>> there is another mayor contestant that I'm not aware of ?
> This separation makes sense to me; repoze.what middleware should be able to
> consume environment variables from any old middleware doing authentication
> "above" it in the WSGI pipeline.  This makes it possible to use repoze.what
> independently from repoze.who, which lets people a more piecemeal approach to
> integration (maybe you already have Apache doing authentication for you, for
> example).

I'm not against this per-se I'm just saying that the main reason of
creating repoze.what (some months ago) was to emphasize it's relation
to repoze.who, now that relationship is gone, back then it was a good
idea, but now this project has (from an outsiders perspective) no
relationship with repoze.* packages. It's not a "reinvention of a zope
package" nor it depends on other repoze components. So what is it?

As for TurboMail. I think it's a good way to go, just like
toscawidgets. The main goal of TG2 was to keep the core simple and
push everything into packages (preferable with wsgi in mind) Both are
great examples of this goal. Identity underwent the same conversion,
but instead of building "from zero" it piggybacked on repoze.who,
which I though was it's main advantage.

The issue with repoze.what is that it was originally an authorization
layer. This proposed change not only takes it outside the
authorization realm, but makes it a direct competitor of repoze.who,
instead of an extension as it was originally planned.

So ones again I'm not saying no, I'm asking why? and if that is a
valid reason will it still be worth naming this package repoze.what?

> - C
Repoze-dev mailing list

Reply via email to