Interacting with mailman remotely through APIs / wrappers
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.htm..., 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/
-----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-----
Hi Ben --
Back last year Joseph Tate of rPath and I cobbled together an XMLRPC interface for Mailman 2.1.7 -- it has been running on lists.gnu.org and gplv3.fsf.org since then.
This month I've been porting it to 2.1.9, filling out the interface to handle moderation requests, and writing unit tests for the interface. The code will probably get released in a working state this week. When it does, I'll announce it here.
If you'd like to know more, feel free to write me off-list.
Cheers!
-jag
Barry Warsaw wrote:
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
Mailman-Developers mailing list Mailman-Developers@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/jag%40fsf.org
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
participants (3)
-
Barry Warsaw -
Ben Sims -
Joshua 'jag' Ginsberg