[Mailman-Developers] Another take at MysqlMemberAdaptor + a migration utility

[Kyrian (list)]

Folks,

Well, after a gargantuan cull of my inbox, it's down from 9,000+ to more
like 9, and as mentioned, I would work on MysqlMemberships.py at that point.

I have, I believe incorporated everyone's non-destructive patches and
comments so far into the distribution (I have erred on the side of
caution with incorporating stuff in, so please don't take offence if I
have not included your contributions), crediting where appropriate, and
pending some testing (as I now have a development environment built in
which to do so) before I send a sourceforge announcement, etc. If anyone
else feels like testing it, I have fairly silently uploaded the latest
version (1.69) of it to the oRe Net Opensource pages, although that has
only been tested to the point of a python syntax check pass.

Considerable thanks go to Adrian Wells for his repeated contributions,
Fil for his large-scale suggestions, and everyone else, I didn't think
for an instant that my very first piece of Python coding would generate
such interest.

In any case, before I go any further with regards to development, since
Mailman appears to be undergoing internal changes that may cause future
issues, and I already have a large TODO list, I'd like the input of the
development team and others on both the progress of Mailman and future
plans, and its relation to my (slightly amended) TODO list for the MySQL
Member Adaptor stands as follows...

Firstly, those items in it which I need help with, or to discuss with folks:

* Figure out how to make passwords work. Currently using "!" as the default
  password, so that things don't barf, but that is probably not the right
  way to go about it. What is the Mailman equivalent of "No password", etc?

* Ensure that what the patch is doing ties up with Barry's input wrt.
what it
  should be doing.

* Check up on whether Adrian Wells is correct with regards to the user flags
  ('hide', 'noemail', 'ack', 'not_metoo', and 'plain'), and hence columns
  in the adaptor's database tables are fully deprecated from Mailman, in
  favour of the user_options flag/column if so, make changes to the adaptor
  accordingly.

* Adrian Wells Bouncer.py patch. Discuss with Mailman team. Is it the
right way
  to go. Moving this patch deeper into the guts of mailman seems to be a
little
  anathema to the whole idea of Member Adaptors in the first place, not to
  mention that it scares me a little ;-)

* Await responses to fil (at) rezo.net's ideas. I would not mind at all
incorporating a migration ultility into the
   MysqlMemberships.py tarball I'm sending out, and I certainly see the
merit of the other suggestions, but some of it
   strikes me as a little premature, or perhaps overkill given various
factors.

And of course the obvious ones, which I shouldn't have much of a problem
with.

* PRIORITY: Database escaping, need to work out how to to this with the
Python
  MYSQLdb module, after all it would only take a well-crafted email to raise
  merry hell as things are at the moment.

* MYSQL_MEMBER_DB_WHERE so you can specify a "WHERE x = y" on all the
queries
  in the database. ???

* MYSQL_MEMBER_DB_SOCKET, to support a local socket connection to the MySQL
  server. This should be easy using the "unix_socket" attribute of MySQLdb's
  connect call.

I guess if anyone would care to add anything to the above or make
suggestions that would be cool, but please try and keep them short, I
don't want 9,000 emails in my inbox again any time in the next six
months or so, please.

K.