[Mailman-Developers] "Orignal" MySQL Member Adaptor - 1.71

kyrian (List) kyrian-list at ore.org
Fri Sep 26 19:48:38 CEST 2008


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/



More information about the Mailman-Developers mailing list