Mailman 3 May 2007 - Mailman-Developers

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 01 Jun '07

01 Jun '07

Thanks John, I had been hoping to avoid command line calls. However, I'm probably just putting unnecessary obstacles up, so unless anybody advises against it I'm going to use subprocess to call the scripts I have to and leave it at that. Ben ----- Original Message ---- From: John Dennis <jdennis(a)redhat.com> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: Lennon Day-Reynolds <lennon(a)reed.edu>; mailman-developers(a)python.org Sent: Thursday, 24 May, 2007 6:21:42 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers On Thu, 2007-05-24 at 09:10 -0700, Ben Sims wrote: > Regarding the Python APIs, I wondered if there is any documentation available? At the moment I am going over the source, which is a bit heavy going. > > For example, I am having trouble working out if it is possible to create a new list from the Python modules directly? > > Any pointers to the right docs here would be appreciated. Your best bet might be to look at the command line interfaces under the /bin directory in the source tarball. For the case cited you'll want to look at bin/newlist. -- John Dennis <jdennis(a)redhat.com> ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

3 2

Moving to Bazaar and Launchpad
by Barry Warsaw 30 May '07

30 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Several weeks ago I asked whether it was time to move the Mailman source code from Subversion to a distribute version control system (dvcs). I appreciate all the great feedback that people provided, both on the public list and in private email. It's clear that moving to a dvcs has widespread support, and that people are willing to learn a new version control system in order to gain the benefits of a dvcs. Several people suggested that we look at Mercurial and git, as well as some other dvcs's. At the time I narrowed the choices to Mercurial and Bazaar because I wanted to stick with a Python-based version control system. Well, I've spent some time playing with both systems, talking to folks, and thinking about the move. Either dvcs would probably serve our needs and either would give us advantages over Subversion. However, I have chosen Bazaar, with hosting on Launchpad. In summary, the advanced branch hosting support offered by Launchpad, combined with the ability to get first hand help for any future problems or wishlists, swayed me to Bazaar. I didn't find anything compelling enough about Mercurial to make a difference, although I'm sure it's a fine dvcs. So, I am going to begin the process of moving our Subversion repository to Bazaar-on-Launchpad. My target date for pulling the switch is Friday June 22nd, 2007. In preparation, I've merged my exp-elixir-branch to the trunk. I've had enough success with this to feel confident that the SQLAlchemy/ Elixir approach is going to work pretty well, and I want to reduce the number of branches we have to import into Launchpad. The Subversion repository will remain available on SourceForge, but after flag day, it will be read only. I've written a wiki page about the switch, available here: http://wiki.list.org/display/DEV/MailmanOnLaunchpad and there are still a few things to work out, but I think we're quite close. Please read that wiki page and let me know if you have any questions. In the meantime, if you currently have write access to the Mailman Subversion repository, please register on Launchpad, request membership in the mailman-coders team, and send me a private email with your Launchpad user id. I'll go through and start approving committers so we'll have everything in place when it's time to finalize the switch. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRly4ZXEjvBPtnXfVAQJfjAQAsHEQYbNyonsFwjTGVa28ZWkSyT/1BLiq V4kqKfLK3/ZVE+6HoWDJ5heHWmbcfyHAXAdz1bR+WvUGdmrRkAkU90848MdUB3p/ k+49VHhux+N541ZENpEXXbIAu0Lu1rVbGMbIT9iMoOhGSHbbUMvkl6gsPc1nIJJ/ llTBJfB5nAU= =dSGG -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 24 May '07

24 May '07

Thanks Lennon, What you describe below seems to be very close to what I am attempting to do, other than that I have been trying to avoid the cron/SSH stuff. I've managed to get basic implemetations of the SOAP stuff working, with a PHP SOAP client talking to a ZSI SOAP server on the Mailman box. Regarding the Python APIs, I wondered if there is any documentation available? At the moment I am going over the source, which is a bit heavy going. For example, I am having trouble working out if it is possible to create a new list from the Python modules directly? Any pointers to the right docs here would be appreciated. Regards, Benjamin ----- Original Message ---- From: Lennon Day-Reynolds <lennon(a)reed.edu> To: mailman-developers(a)python.org Sent: Monday, 21 May, 2007 10:59:52 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: > [...] > I wonder if there isn't a cleaner way to integrate PHP and Python. > Does anybody know? Or is some form of IPC really the only way to go? > > Writing command line interfaces to provide the functionality you want > should not be difficult at all, if you are comfortable writing Python. I've built applications that manipulate Mailman data using both the internal Python APIs and the command-line scripts, and I can say that both have their pleasantries and annoyances in about equal share. Generally, the command-line tools are "good enough," and are certainly easier to expose to anything not written in Python. However, the argument handling is just different enough between tools to make a totally general bridge difficult to write without special cases for each action (add/list/remove member, add/show/delete list, etc.). We have Perl and Ruby apps using the CLI tools to manipulate list membership, though most run either under cron or an interactive SSH session to the Mailman server. The Python APIs can be faster, and certainly give you more powerful (read: unrestricted) access to list data. For operations over large numbers of lists, though, the unmarshalling of list pickles seems to be the limiting factor, not the Python startup overhead. One such all-Python application I've developed for use here at Reed uses web.py and the Mailman Python APIs to expose a quick 'opt-in' interface to a subset of our campus mailing lists. We rely on our LDAP directory and web single-sign-on infrastructure to simplify the subscription process: basically, after completing SSO auth, users can simply check the subscription box next to each list name, and be automatically added to (or removed from) it. I'm eagerly looking forward to MM3 (or at least the SQLAlchemy branch) making much of the hackish local customization work I've done unnecessary. The XML-RPC interface sounds interesting, too, though I don't know that it will really offer enough to prompt a rewrite of all our command-line driven add-ons. Lennon Day-Reynolds Systems Programmer Reed College -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUghIRtirLnfvQskRAoaMAKCpAwxGPFJzXyEMgTJDLyLo7Hs+uwCdHP/l HMJgJcyut94SzbgOC9IAcRo= =77oH -----END PGP SIGNATURE----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/benjaminsims%40ya… Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

2 1

Re: [Mailman-Developers] Looking for a Developer for a MailMan module
by Nick Ashton-Hart 23 May '07

23 May '07

We are currently running 2.1.9 cp2. On 23/05/07, Torsten Schlabach <TSchlabach(a)gmx.net> wrote: > Hi Nick! > > If nobody stepped up so far, I might be interested, depending on the urgency ... > > For what version of Mailman would you need it, 2.1.x or 2.2? > > Regards, > Torsten > > -------- Original-Nachricht -------- > Datum: Tue, 22 May 2007 19:22:03 +0100 > Von: Nick Ashton-Hart <nick.ashton-hart(a)icann.org> > An: mailman-developers(a)python.org > Betreff: [Mailman-Developers] Looking for a Developer for a MailMan module > > > Dear MailMan developers: > > > > Barry suggested that I contact you all in reference to the following > > and see if any of you are interested. > > > > I'm looking to contract a developer to code a module for MailMan, so > > that MailMan can interface to a machine translation API provided by > > SYSTRAN, such that inbound emails would get translated into the > > default language chosen by the user individually from the MailMan > > options page. > > > > They would receive as the default output in the body of the email the > > translated text, with the original text as an attachment. Any > > attached files would be left untouched but passed through as defined > > by regular mailman settings. > > > > Of course this would be a paying engagement. > > > > -- > > Regards, > > > > Nick Ashton-Hart > > Director, At-Large > > ICANN > > PO Box 32160 > > London N4 2XY > > United Kingdom > > Main Tel: +44 (20) 8800-1011] > > USA Tel: +1 (202) 657-5460 > > Fax: +44 (20) 7681-3135 > > mobile: +44 (7774) 932798 > > email: nick.ashton-hart(a)icann.org > > Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / > > Skype: nashtonhart > > Online Bio: https://www.linkedin.com/in/ashtonhart > > > > > > > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers(a)python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > > Searchable Archives: > > http://www.mail-archive.com/mailman-developers%40python.org/ > > Unsubscribe: > > http://mail.python.org/mailman/options/mailman-developers/tschlabach%40gmx.… > > > > Security Policy: > > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- -- Regards, Nick Ashton-Hart PO Box 32160 London N4 2XY United Kingdom UK Tel: +44 (20) 8800-1011 USA Tel: +1 (202) 657-5460 Fax: +44 (20) 7681-3135 mobile: +44 (7774) 932798 Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / Skype: nashtonhart Online Bio: https://www.linkedin.com/in/ashtonhart

1 0

Looking for a Developer for a MailMan module
by Nick Ashton-Hart 23 May '07

23 May '07

Dear MailMan developers: Barry suggested that I contact you all in reference to the following and see if any of you are interested. I'm looking to contract a developer to code a module for MailMan, so that MailMan can interface to a machine translation API provided by SYSTRAN, such that inbound emails would get translated into the default language chosen by the user individually from the MailMan options page. They would receive as the default output in the body of the email the translated text, with the original text as an attachment. Any attached files would be left untouched but passed through as defined by regular mailman settings. Of course this would be a paying engagement. -- Regards, Nick Ashton-Hart Director, At-Large ICANN PO Box 32160 London N4 2XY United Kingdom Main Tel: +44 (20) 8800-1011] USA Tel: +1 (202) 657-5460 Fax: +44 (20) 7681-3135 mobile: +44 (7774) 932798 email: nick.ashton-hart(a)icann.org Win IM: ashtonhart(a)hotmail.com / AIM/iSight: nashtonhart(a)mac.com / Skype: nashtonhart Online Bio: https://www.linkedin.com/in/ashtonhart

2 1

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 22 May '07

22 May '07

Thanks again for your helpful reply. In particular, I really like the sound of being able to use different databases for different types/sources of data; this sort of ability to integrate is exactly the sort of thing I am envisioning. Re: integrating PHP and Python: I did, after various search combinations, find this presentation from 2002: http://www.csh.rit.edu/~jon/pres/php-2002/pip-applications.ppt, and consequently http://www.csh.rit.edu/~jon/projects/pip/. However, nothing seems to have happened on this since 2002 and so I'm not really keen on it. In any case, thinking about it more I realise that since I want to be able to use a standalone (and possibly remote) Mailman server a PHP/Python combination probably wouldn't be perfect. One thing I did pickup from the presentation above was his use of the Python Mailman modules in his wrapper scripts. I've been looking more into what I can do using those, rather than the command line. At the same time, I've been looking into what can be done (and how easily) using Web Services. In particular, I like the sound of the Zolera SOAP Infrastructure, which seems to provide a very simple way to access Python functions over SOAP. So, my thinking at the moment is to hack up a single Python object which wraps the relevant Mailman modules for the functionality I need to use, then use ZSI to expose that object as a web service. If I need to, I can always just call the command line scripts from that object, so I wouldn't be cutting off any options. This seems to me, at the moment, to be the best compromise between doing it 'properly' and my need to have something up and running quickly, however ramshackle. Benjamin ----- Original Message ---- From: Barry Warsaw <barry(a)python.org> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: mailman-developers(a)python.org Sent: Saturday, 19 May, 2007 12:58:30 AM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 17, 2007, at 8:39 AM, Ben Sims wrote: > With regards to Mailman 3, from my reading I understand that this > will implement SQL-type storage for all configuration and list > data. This would completely take care of my needs in this case I > think; would you perhaps be able to give us a rough idea of progress? Things are moving along well. My work these days has been to complete the data model using Elixir and SQLAlchemy. I had a breakthrough with Elixir a few days ago, so now I'm just working on completing the model, related interfaces, and doctests. My plan is to have a working database backend asap so I can unbreak all the higher level stuff that depends on the data model. Right now I'm working in a branch, but I am going to very soon merge this back to the trunk, even though it will break the trunk. I speak more about this in some later postings. I'm trying to be very diligent about writing interfaces to describe how Mailman interacts with the data model, so you could potentially back it with different storage mechanisms. The idea is that you might want to put your list data in Mailman's default SQLite database, but you might want to get your user data out of your enterprise database. By writing your own implementations of Mailman's interfaces, you should be able to do that. > As a garden-variety PHP developer and Mailman rookie, I doubt how > far I am capable of going deep into Mailman itself to implement a > solution for this. I would be happy to do the research before > dismissing the idea though, if you could point me in the direction > of some bedtime reading on the subject. Given the time I have > available and the limited functionality required, I'm very much > leaning towards the cheapest hack option - which seems likely to be > simply executing command line commands. I wonder if there isn't a cleaner way to integrate PHP and Python. Does anybody know? Or is some form of IPC really the only way to go? Writing command line interfaces to provide the functionality you want should not be difficult at all, if you are comfortable writing Python. > Regarding your questions: > > -- What functionality do you want to expose? > > Not much. To start with, creating and removing lists and adding and > deleting subscribers would probably be enough. Creating and removing lists are a bit hackish now because the logic to do so is spread out in a couple of places. However see the bin/ newlist script or Mailman/Cgi/newlist.py module for examples. The former may already do what you need here. This will get much easier in MM3. Likewise for adding and deleting subscribers. > -- How would you handle security? > > To be honest, I hadn't even got as far as thinking about that, > since I'm not really clear on the mechanisms involved. > > - - Will you have to re-implement much of the CGI logic? > > Again, I haven't gone through closely enough to give a decent > answer. If I was hacking something up which did use the Web > Interface as a gateway, I would be more likely to use Mechanize to > fake a browser and do the intereacting. Ugly I know, but I'm > familiar with that so I could get it to work. Probably much easier to use the existing command line scripts, augmenting or writing your own as needed. Remember you can also do a lot with bin/withlist scripts. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRk4hh3EjvBPtnXfVAQIQ+AP9HupG3WJ9X8hD+vsowrLCq5FwWlw194P9 iB2qHhTbafFlURf/7dXt+JLfX7UjTchydsBPaNR00UwBUZcMohTXCbJJSEi+kMwg 7p32bknigvmC/3qujLzkZz08lwUo86mK6e7q/w55O6fb1DAXVfYiw+1LpBJagZ7h E/iTlLiJHOI= =yIkR -----END PGP SIGNATURE----- ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

2 1

Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers
by Ben Sims 22 May '07

22 May '07

Many thanks for your speedy response, Apologies for any ignorance displayed regarding Mailman - I have begun experimenting with it only recently as a way to add mailing list functionality to the existing PHP application I mentioned. (As a side note, a big thank you to whoever builds the Debian package - completely painless, especially compared with Sympa...) With regards to Mailman 3, from my reading I understand that this will implement SQL-type storage for all configuration and list data. This would completely take care of my needs in this case I think; would you perhaps be able to give us a rough idea of progress? As a garden-variety PHP developer and Mailman rookie, I doubt how far I am capable of going deep into Mailman itself to implement a solution for this. I would be happy to do the research before dismissing the idea though, if you could point me in the direction of some bedtime reading on the subject. Given the time I have available and the limited functionality required, I'm very much leaning towards the cheapest hack option - which seems likely to be simply executing command line commands. Regarding your questions: -- What functionality do you want to expose? Not much. To start with, creating and removing lists and adding and deleting subscribers would probably be enough. -- How would you handle security? To be honest, I hadn't even got as far as thinking about that, since I'm not really clear on the mechanisms involved. - - Will you have to re-implement much of the CGI logic? Again, I haven't gone through closely enough to give a decent answer. If I was hacking something up which did use the Web Interface as a gateway, I would be more likely to use Mechanize to fake a browser and do the intereacting. Ugly I know, but I'm familiar with that so I could get it to work. Sorry that I don't have the experience to come up with better ideas on this; as I said, I welcome input from anybody that has already attempted this kind of work. Regards, Benjamin ----- Original Message ---- From: Barry Warsaw <barry(a)python.org> To: Ben Sims <benjaminsims(a)yahoo.com> Cc: mailman-developers(a)python.org Sent: Wednesday, 16 May, 2007 4:05:53 PM Subject: Re: [Mailman-Developers] Interacting with mailman remotely through APIs / wrappers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 16, 2007, at 5:00 AM, Ben Sims wrote: > All > of these are rather clunky. My dream response would be some sort of > Web > service / API interface with a corresponding PHP client object, but I > haven't been able to find any evidence of this existing. I think this could be handled fairly easily, and it would make an excellent project for Mailman 3. You could prototype the work for Mailman 2.1 fairly easily too. The way I'd go about thinking about this would be to implement a qrunner based on Python's standard SimpleXMLRPCServer module. While not technically a 'queue runner', we already have some precedence in the trunk for running other types of long-running processes from the qrunner architecture, so while a slight misnomer, it's quite workable. The questions of course are - - What functionality do you want to expose? - - How will you handle security? - - Will you have to re-implement much of the CGI logic? I think you could pretty easily throw together the architecture for this and then start to answer the other questions. In Mailman 3 I'm trying hard to get functionality that lives only in the CGI or command line scripts accessible through the standard Mailman package. One other thing to think about: In the trunk, we already have a wsgi- based web server which should allow sites to swap in their own HTTP- based access to Mailman if they wanted (e.g. via Zope, Django, TurboGears, etc.). Many of these web publishing frameworks also have XMLRPC publishing. I don't know what the standards there are, but IWBNI we could swap those publishing mechanisms as well. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRksBsnEjvBPtnXfVAQKOqgP9HzgbldPeM8QNEsbN98PbksHVzP/qBOEN isXu3dDHGvtTx8DxJbgtQ2R0qSPJU7nsKvIC8O1Iqw01t+89MZLVEbCAx+uiPj1K wPXsYoitDW4XeN7CCfBE+xoEFL++mRqH6K3MC3zOavqt6HZ07hbQBKLE/XmMEepR BAcTbwnUEjI= =nwzh -----END PGP SIGNATURE----- ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

3 2

Interacting with mailman remotely through APIs / wrappers
by Ben Sims 16 May '07

16 May '07

Hello to all, I'm currently looking into ways to interface with Mailman remotely. Specifically, I want to use a PHP based application on a different server to create and delete lists and add and remove subscribers. There have been discussions touching on this on this list in the past (for example http://mail.python.org/pipermail/mailman-developers/2005-November/018299.ht…, and http://mail.python.org/pipermail/mailman-developers/2001-April/008549.html seven years ago). As far as I can see though, nothing ever came of these in terms of stable, released products. Does anybody here have any information or ideas as to the best way to achieve this sort of thing? At the moment, I am looking at: - faking POST requests to the web interface - writing files for consumption by config_file and then sending them over - sending requests by email to the list - writing shell files to be transferred to the target server and executed All of these are rather clunky. My dream response would be some sort of Web service / API interface with a corresponding PHP client object, but I haven't been able to find any evidence of this existing. Thanks for any tips, Benjamin ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

3 2

Styling patch
by A.M. Kuchling 14 May '07

14 May '07

Patch #1415956 from Bryan Carbonnell adds CSS for styling purposes and changes the HTML to be valid XHTML1.0. It still needs some tidying up, and it still uses tables for layout, but that patch takes us halfway there. It presents one big compatibility issue that will probably need to be fixed. The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with CSS class declarations. It's probably unacceptable to break the use of these settings, so there needs to be some compatibility fix. Colours could be substituted into the .css file somehow, or a 'style' attribute could be added as well as a 'class' attribute. Does anyone have suggestions for what to do? Patch URL: <http://sourceforge.net/tracker/index.php?func=detail&aid=1415956&group_id=1…> [Aside: are there many patches in the tracker that could be useful? I don't know how actively they've been getting processed. Does there need to be a push to process bugs and patches?] --amk

10 20

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8215]branches/exp-elixir-branch/Mailman/Handlers/ Scrubber.py
by Mark Sapiro 12 May '07

12 May '07

bwarsaw(a)users.sourceforge.net wrote: >Log Message: >----------- >Forward port more of Mark's r8204 fixes: > >- Handlers/Scrubber.py > Fixed a scrubber issue where the i18n translated 'next part' separator > can be garbled if the list charset is different from the message. > >Note that the other parts of the Scrubber.py and Decorate.py changes in r8204 >have already been applied to the trunk. > >Modified Paths: >-------------- > branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py > >Modified: branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py >=================================================================== >--- branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py 2007-05-10 03:08:48 UTC (rev 8214) >+++ branches/exp-elixir-branch/Mailman/Handlers/Scrubber.py 2007-05-10 03:59:31 UTC (rev 8215) <snip> >@@ -331,6 +343,13 @@ > charsets.append(partcharset) > # Now join the text and set the payload > sep = _('-------------- next part --------------\n') >+ # The i18n separator is in the list's charset. Coerce it to the >+ # message charset. >+ try: >+ s = unicode(sep, lcset, 'replace') >+ sep = s.encode(charset, 'replace') >+ except (UnicodeError, LookupError, ValueError): >+ pass > rept = sep.join(text) > # Replace entire message with text and scrubbed notice. > # Try with message charsets and utf-8 I'm not sure the above patch is necessary (or even correct) in the trunk. I looked at Tokio's port of my Scrubber.py changes to the trunk. and it looked to me that Tokio had accounted for this issue in a different way. BTW, I haven't looked at all of Barry's port of my recent patches, but I also ported them to my working copy of the trunk. I didn't commit them because although I'm sure they were ported correctly, I wanted to run a few tests first. Unfortunately, I updated my working copy from the trunk before starting and then found that the trunk's current state was not usable for me :-( -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1