Fil wrote:
Incidentally, since Fil seems to be taking all the credit for what I
started I think he should actually put a proper credit in there for me,
linking to my business website at http://www.orenet.co.uk/ rather than
the vague passing mentions that are in the docs/code of his version of
the system at the present time.
I'm sorry if I did anything not appropriate. From what you see in the code
http://trac.rezo.net/trac/rezo/browser/Mailman/MySQLMemberAdaptor/MysqlMemberships.py
it seems that the mention you require is there.
Yes, that's good, although it's just a copy from my original code ;-)
Please tell me how to make it better and I will correct it.
"real people" don't read source code, if you can, something in the
README as well would be good for me, thanks.
More to the point, I fixed a few issues and added some features. Do
you plan to take these into account in "your" version? If not we are
necessarily "forking" this piece of code, regrettably, because I need
"my" version in production.
That wasn't what I was on about.
Don't get me wrong here, I want the same as everyone else; excellent
quality SQL support integrated into Mailman. (note SQL, not MySQL, as a
portable backend system is not used by my original adaptor [it's using
the MySQL-specific MYSQLdb?] or I believe your fork of it!?), and I
don't mind that you have snarfed my code and extended it in your own
way, I'm glad of it. I'd just like a credit that 'real' users might
actually read ;-)
In order for that to happen, and for either version to be incorporated
into Mailman 'proper', an agreement needs to be reached (and I may be
out of date here, and one already has) betwen you, perhaps me, and the
core mailman developers about how to solve at least the following:
- The conflict between the old pickle way of doing things of iterating
over a get-singular-record method numerous times rather than a
grab-multiple-records-and-return-in-the-right-format which is more the
way SQL works effectively. Whether that's a rewrite, or some way of
overriding the existing methods to implement them better, I don't know.
Perhaps I can look into this soon. Any hints from the core guys?
- The two pages of suggested patches and extra changes to the core of
mailman, eg. the CGI's and how everything should be merged together.
- Implementation of getMembersMatching() - You *CAN* do regexps in mysql
;-) Although perhaps that would necessitate use of a mysql version check
at instantiation time, or in the ping() function?
That is what I *don't* like about your patch, I appreciate you needed to
solve certain problems to get it going, but in doing so, I figured you
have made it less able to integrate into the Mailman core, which is why
I didn't just point everyone to your version, and kept mine as-is until
I found some time for it.
I really like the 'extend.py' method you came up with because it's waaay
better than my method of importing the thing, and your documentation is
probably better than mine, too.
I note that you are in France (according to whois), which isn't
impossibly far from London, where I am, perhaps we can get our heads
together on this directly, after all France is the home of Kronenburg,
which is a good reason for me to go there. I'm afraid I can't think of
any others apart from Mailman and Kronenburg, though ;-)
K.
PS. Is Trac really as good as people seem to think it is? I've not
started using it, but I certainly like the *look* of it?
--
Kev Green, aka Kyrian. E: kyrian@ore.org WWW: http://kyrian.ore.org/
Linux/Security Contractor/LAMP Coder/ISP, via http://www.orenet.co.uk/
DJ via http://www.hellnoise.co.uk/
_______________________________________________
Mailman-Developers mailing list
[email protected]
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
