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…
-----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-----
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
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
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
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…
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…
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/
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
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