[Systers-dev] Moving from Pickle Membership to Store in the Postgresql Database

Anna Granudd anna.granudd at gmail.com
Tue Jun 8 07:20:03 PDT 2010


Tomorrow at 19:00 GMT works for me.

Anna

On Tue, Jun 8, 2010 at 1:55 PM, Jaideep Khandelwal <jdk2588 at gmail.com>wrote:

> > No, you probably want to make this unified record at the very beginning,
> or
> > it's too messy (it's easy to treat the first as a distinguished case, not
> so
> > much the second).  It's not a single signon unless you have a single
> > location for user name and password.
> >
> > But my point was that you don't want redundancy (from there come errors),
> > so you need to think about how things change when this information is not
> > stored in the individual list.  Especially because you don't want to have
> to
> > modify the code for every application that we want the single signon for
> (I
> > think that you can assume that applications outside of mailman have some
> > sort of openid or similar system hook that you will be able to use. Do
> you
> > want to create such a hook for mailman?  Do you want mailman to be just
> > another application in this set or "special"?
> >
>
> I would better prefer the mailman to be the special application as the data
> would be collected from the users coming to the Mailman should only be
> storing the credentials , and yes the hook will be for mailman that is to
> be
> created and it should be restricted for the systers concerned site.
>
>
> >
> >> > And I think the bounce information (if I'm understanding it correctly)
> >> > needs
> >> > some serious thinking through.  Different applications may have
> >> different
> >> > ways they count bounces, so you may not be able to have a single "if
> it
> >> > bounces this many times, drop them" metric.  And if someone belongs to
> >> 10
> >> > systers.org lists, and the system sends out password reminders for
> each
> >> > list
> >> > (or something similar) and they all bounce due to a temporary problem,
> >> we
> >> > wouldn't want to count that as 10 bounces.  So I think you need to
> think
> >> > through the various pros and cons of keeping bounce information in a
> >> > central
> >> > place vs. for each list.
> >> >
> >> > I would like to have an IRC meeting and have a discussion about this
> >> issue.
> >>
> >
> > This sounds like a good idea.  Unfortunately, I'm about to go off on
> > vacation, where I won't have reliable internet access (till next Monday).
> >  What time zone are you in?  If we make it relatively short, I might be
> able
> > to find time during the day (California time) on Wednesday before I
> leave.
> >  I think Malveeka is in the same time zone as I am.  Who else should be
> in
> > the meeting?
> >
> My time zone is : +5.30 GMT
> I am busy with my Exams  so Wednesday will not be possible for me and after
> that it will be too late for you and Malveeka. It would be nice if we can
> fix it on Wednesday 1900 hrs (GMT) and for the meeting it would be nice if
> Anna and Pinar could be present so that we can discuss the working on
> Database issue.
>
> I don't think I understand what you said here.  I'm talking about storing
> > ONLY the login information, not any data needed by a specific
> application;
> > that is, what you store rather than where you store it.
> >
> > While we definitely want to be able to use this for CMS, wiki, etc., I'm
> > not sure how your approach does that.  I think we have to assume that we
> > aren't willing to make code changes to every new application that we
> install
> > on the systers machine.
> >
> > No , for that we would rather prefer the Open ID provider that will be
> used
> for the applications and  many of the applications such as CMS , wiki now
> have the modules for OpenID Clients .
>
> Regards
>
> Jaideep
>
>
> To unsubscribe from this conversation, send email to <
> systers-dev+mentor+unsubscribe at systers.org<systers-dev%2Bmentor%2Bunsubscribe at systers.org>>
> or visit <
> http://systers.org/mailman/options/systers-dev?override=67&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to systers-dev+mentor at systers.org<systers-dev%2Bmentor at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to <
> systers-dev-request at systers.org> with subject unsubscribe.
>

To contribute to this conversation, send mail to <Jaideep Khandelwal >


More information about the Systers-dev mailing list