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

[Robin Jeffries]

And for me also.  Tomorrow == Wed, June 9

Robin

On Tue, Jun 8, 2010 at 7:20 AM, Anna Granudd <anna.granudd at gmail.com> wrote:

> 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>
> <systers-dev%2Bmentor%2Bunsubscribe at systers.org<systers-dev%252Bmentor%252Bunsubscribe 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><
> systers-dev%2Bmentor at systers.org <systers-dev%252Bmentor at systers.org>>
> > To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> <systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>>
> > >
> > To unsubscribe entirely from systers-dev, send email to <
> > systers-dev-request at systers.org> with subject unsubscribe.
> >
>
>
> 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.
>