[Mailman-Developers] Interfacing to Mailman data

[Kevin McCann]

On Wed, 2003-07-30 at 13:38, Chris Boulter wrote:
> On Mon 2003-07-28 11:29:52 -0400, Kevin McCann wrote:
> > A while ago I mentioned that I was interfacing with Mailman (via PHP) by
> > issuing the /bin commands and parsing the results.
> 
> I get the feeling a lot of people are doing this.
> 
> > What about having interface-friendly versions of these commands? So,
> > instead of executing the /bin/list_lists command and getting ...
> ...
> > ... I could instead execute a different command and get a
> > comma-delimited list.
> 
> This would help with your parsing, but isn't as good as a proper API.
> Mailman 3 should address this problem, from Barry's postings in this thread:
> 
> http://mail.python.org/pipermail/mailman-developers/2003-July/thread.html#15383

Right. But it was from that thread in which I read the following:

======

that's the most expedient way to hook Mailman up to foreign systems.  I
/would/ however like to have some requirements for that hookup so we can
tailor the scripts to those specific needs.  For example, the current
crop of scripts in bin/ were written primarily to solve a problem that
the human operator was having.  That may not be the most efficient or
useful interface for hooking two programs up.

-Barry
=======


Which is what my post was based on. It sounded like there was going to
be an effort to whip up some versions of the /bin commands that would do
the kinds of things I was talking about. But Barry also indicated he
wanted input with regard to the requirements. And I also know he's
already got a lot on his plate. But I do sense that it's not just little
ol' me that could benefit from a set of modified /bin commands. And I'd
like to help in this exercise in any way I can. 

> So, as the other poster who replied to your mail said, you could address the
> problem yourself and try to contribute your improvements, but it doesn't
> sound like they'll be useful for Mailman in the longer run.

Version 3 could be a long way away. I do need to take the other
approach. If an API eventually comes to fruition, all the good, and I'll
make the adjustments in my PHP app when that happens.

> Incidentally, as far as list_lists goes, the --bare parameter will give you
> output which is more machine-friendly than the default.

Yes, I saw that. Unfortunately it does not return the list description,
which I sometimes need. 

I'm going to dig in and see what I can get done and will certainly share
ouptuts that might be of value to others.. 


Cheers,
Kevin