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

[Robin Jeffries]

Some more comments.  We are making progress.

On Mon, Jun 7, 2010 at 10:53 AM, Jaideep Khandelwal <jdk2588 at gmail.com>wrote:

> Hi Robin, Malveeka
>
> Sorry for the late reply as I was not online for a day. Q&A leads to
> healthy
> and productive work.
>
>
> The primary email address is the user name (and we keep both the primary
> and
> > secondary emails in that database)
> > I think the password is there too.
> > It doesn't have the user options or any syncing with other lists (each
> list
> > has its own database tables).
> >
> > I'm not sure what you mean by bounce info -- how many times messages have
> > bounced?  That's not there.
> >
> > I think the biggest rethinking is that now we treat all email lists
> > separately.  How would the schemas have to change (and what would have to
> > change outside the single signon) to have one master copy.
> >
> >
> Now , having a Separate Database for the users joining the lists and the
> user information could be done in a manner such if a user 'A' comes to
> systers.org mailing lists and join  one lists , after that she joins the
> second list then the user's data will be checked in the membership database
> that the user with this particular username and emailin address does not
> get
> stored once again for the same credentials , overall avoiding the
> redundancy
> for the data.
>
>
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"?


> > 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?


>
>
> > An alternative way to do this would be to just have a central table of
> > username (primary email) and password, and interpose for each app a
> method
> > where you send the single signon module the login credentials and it
> sends
> > you back valid/invalid.  That seems like a lot less work; what would be
> the
> > value of the additional things you are adding here?
> >
> > I agree that there is an alternative for storing the data into a central
> database , but it would get clumsy  for storing  credentials with the
> diffrent lists, rather one common database would be better that will avoid
> Redundancy , what IMO is to keep these credentials common and if a user
> want
> to use the previous credential that she used for the first list , them it
> could be also used by providing the same credentials to the second. Now the
> app could be for many applications like CMS, Wiki , Planets as well .
>

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.


>
> > And how does your database interact with the MM3.0 database?
> >
> > That is something that I am about to discuss with  Malveeka
>
> Some more suggestions would be awesome!!
>
> 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.
>