-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 26, 2008, at 1:48 PM, kyrian (List) wrote:
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 ;-)
Note that Mailman 3 is backed by the Storm ORM <http://storm.canonical.com >. Storm supports SQLite, MySQL and PostgreSQL out of the box, and it is my intent that MM3 should support all three out of the box, with either a simple configuration setting or at most a plugin written against documented and supported APIs. All the current tests use SQLite since that comes with Python 2.5.
I would welcome developers to download and try the code, and to submit branches or patches that improve the compatibility with MySQL or PostgreSQL. I personally have not tried it with either database.
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:
IMO, Mailman 2.2 should not change the pickle-based approach to persistency. I also think we should be careful about changing any APIs to the data model that MM2 uses internally. Mark is an excellent programmer and tests the code very well, but I always cringe when I think about how few unit tests there are in the MM2.x code base. That's another mistake of mine that I'm trying to correct in MM3.
Mailman 3 also uses Zope interfaces heavily, and the code is careful to be written against these formal interfaces. In theory this should mean that it doesn't matter whether the data persists in a supported database, LDAP, Excel spreadsheet or flat files, with a properly written implementation of those interfaces, it should Just Work. Such implementations should be easily hooked into MM3 via its documented plugin interface.
I'm soon going to be undertaking a bit of reorganization of the code. I want to make it absolutely clear what is core functionality and what is add-on. For example, pickup of email, moderation decisions, munging operations, and delivery are all core functionality. Email commands, RESTful admin control, command line operation, web interface are all add-ons. A little bit of reorganization will make that more clear, and I intend to release the next alpha once the core is functional.
- 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?
I hope the MM3 APIs are much more efficient for this.
- 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.
I'm not quite sure what you're asking for here.
- 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?
Can you explain what this is used for? In MM3, the core membership construct is the 'roster'. The interesting thing is that a roster is just a database query (for the SQL backend), so you could define any number of queries to answer various membership questions.
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 ;-)
Aside: I'm going to be in London the last two weeks of October, and while it'll be very work focussed, I'd love to arrange a meet-up with any UK Mailman hackers.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjdWBYACgkQ2YZpQepbvXG9FQCfWPD5nlkiIju2aUz0MXkUxVxq QMMAn3awr3PVSosJjgEjRx3qOThi6VgP =lja4 -----END PGP SIGNATURE----- _______________________________________________ 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
