The TG2 docs are update.
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.
--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
>
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
