On Monday October 27, 2008 08:10:25 Mark Ramm wrote:
> The TG2 docs are update.

Thank you very much!

> In principle I totally support keeping the authentication framework
> stuff form being tg2 specific.   But I do want to make sure that the
> controller decorator API that TG2 uses is still supported in the
> repoze.what framework.  I don't at all mind if its just one of many
> supported interfaces to this stuff.

Sure, what I basically propose is merge both documentations and plugin 
namespaces. The new project namespace, if agreed, would just be a consequence 
of this -- so the APIs of both packages won't need to change.

Another thing that we may be able to do is have the ability to define both 
authentication and authorization settings in an .ini file (say, something like 
"auth.ini"), just like repoze.who does with authentication.

Cheers.

> --Mark Ramm
>
> On Sun, Oct 26, 2008 at 5:54 PM, Gustavo Narea <[EMAIL PROTECTED]> wrote:
> > Hi everybody.
> >
> > I'm working on the authorization framework for TurboGears 2, which is
> > based on repoze.who, and I'm planning on making it
> > TurboGears-independent, so that more developers may take advantage of the
> > framework. In fact, it can be used outside of TG with a couple of minor
> > modifications.
> >
> > But instead of starting a new independent project, I would like to work
> > closely with repoze.who.
> >
> > I find it wise to keep repoze.who independent of authorization-related
> > tasks, but it's unavoidable to keep the authorization system independent
> > of the authentication. You can use repoze.who without
> > tgext.authorization, but the opposite is impossible (its core
> > functionality works as a repoze.who metadata provider).
> >
> > The consequences are that while documenting tgext.authorization I have to
> > document the repoze.who functionality I mention in the former and it'd be
> > a bit annoying to maintain plugins for both frameworks (if I maintain a
> > repoze.who LDAP plugin, should I start a new project just to add support
> > for tgext.authorization and make it work in the
> > tgext.authorization.plugins namespace?).
> >
> > I propose to keep developing the authentication framework independently,
> > but merge both documentations and both plugin namespaces. Specifically, I
> > have two options in mind:
> >  1.- Turn tgext.authorization into repoze.what ("who" -> authentication;
> > "what" -> authorization). But this won't solve the problem with the
> > documentation nor the plugins.
> >  2.- Start a new project under a new namespace (possibly under
> > repoze.*?), made up of the modules {project}.authentication (former
> > repoze.who), {project}.authorization (former tgext.authorization),
> > {project}.plugins as a namespace for plugins (plugins may add
> > {project}.authentication's identifiers, authenticators, challengers
> > and/or metadata providers, as well as {project}.authorization's group
> > and/or permission source adapters) and another module that will act as
> > the "glue" to enable authorization. Also, both documentations would be
> > merged.
> >
> > Unfortunately, the documentation for tgext.authorization has been
> > recently included in TurboGears', and TG2 online docs are out-of-date at
> > this moment. So, if you want to learn more about tgext.authorization, you
> > may download and build the TG2 docs (check the auth tutorial):
> > http://svn.turbogears.org/docs/2.0/docs/
> >
> > Of course, no offense would be taken if you prefer not to merge both
> > projects
> >
> > :)
> >
> > Cheers!
> > --
> > Gustavo Narea.
> > http://gustavonarea.net/
> >
> > Get rid of unethical constraints! Switch to Freedomware:
> > http://softwareliberty.com/
> >
> > _______________________________________________
> > Repoze-dev mailing list
> > Repoze-dev@lists.repoze.org
> > http://lists.repoze.org/listinfo/repoze-dev

-- 
Gustavo Narea.
http://gustavonarea.net/

Get rid of unethical constraints! Switch to Freedomware:
http://softwareliberty.com/

_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to