registration / openid / account management
James Tauber
integrating Simon's django_openidconsumer work with django.contrib.auth.
In a Hot Club of France context, I'm wondering which would be better:
- a single "account management" app that combines (and in effect
replaces) django-registration, django_openidconsumer and the
integration glue
- three separate apps in addition to django.contrib.auth
Obviously there are perfectly legitimate reasons for wanting django-
registration without openid or openid without django-registration.
But should the Hot Club goal be to keep these loosely coupled or to
provide a single "batteries included" account management app?
James
--
James Tauber http://jtauber.com/
journeyman of some http://jtauber.com/blog/
James Bennett
> Obviously there are perfectly legitimate reasons for wanting django-
> registration without openid or openid without django-registration.
When I first released the registration app, someone asked about
integration with OpenID; I marked it wontfix because, personally, I
think the two are orthogonal to each other, but I'm open to being
convinced otherwise.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
James Tauber
On 18/08/2007, at 2:17 AM, James Bennett wrote:
>
> On 8/18/07, James Tauber <jta...@jtauber.com> wrote:
>> Obviously there are perfectly legitimate reasons for wanting django-
>> registration without openid or openid without django-registration.
>
> When I first released the registration app, someone asked about
> integration with OpenID; I marked it wontfix because, personally, I
> think the two are orthogonal to each other, but I'm open to being
> convinced otherwise.
Ross Poulton's implementation (which I have yet to try but hope to in
the next 12 hours) keeps the registration app separate from
django_openidconsumer and provides a 3rd glue app.
Benoit Chesneau's implementation is a patch to django_openidconsumer
itself and doesn't use your registration app.
I don't know what Simon's approach is / will be.
Obviously what Simon does with django_openidconsumer is up to him. He
may choose to provide full registration capability in his project.
But as I suggest above, I think there's definitely value in keeping
them separate because there are people that will want just one but
not the other.
But the question I have in mind is: can we still package them up in a
way that someone who does want a drop in "account management"
solution to kick-start their django website development. Or, if HCoF
doesn't do the packaging, at least make sure the pieces are
individually written in a way that they play nicely together.
The proof for the latter is largely in how straightforward Ross
Poulton's implementation was -- I'm about to check that out.
James T