Developers of Sympa

[Mark K <address@concealed>]

On Thu, 20 Dec 2007 10:16:48 +0100
Olivier Salaün <address@concealed> wrote:

> Hi Mark,
> 
> Mark K a écrit :
> > I am setting up an installation of sympa inside of my company.  I am
> > very pleased with sympa.  My first suggestion is to flesh out the
> > SOAP interface more.  I'm sure this is on the agenda and I am
> > willing to try to help out some, too.
> >
> >   
> You're welcome to contribute of course.
> > The main issue I am at now is about topics.  I am integrating sympa
> > into an internal sourceforge instance we have.  
> What sourceforge software are you using?
A heavily modified version based upon the last open version that
sourceforge.net had.  I think that was v2.5

> > We had previously
> > been using mailman and I am trying to get sympa more tightly
> > integrated into our main sourceforge interface than mailman was.
> > SOAP is helping.  I am planning on using SOAP to list the mailing
> > lists associated with a sourceforge project by making a topic for
> > each project that creates mailing lists.  However, there is no
> > interface whatsoever that I see in wwsympa, sympa, or SOAP to edit
> > topics.  It seems one has to just edit etc/topics.conf manually. 
> >
> >   
> That's an interesting feature to add. Currently topics.conf is only 
> edited manually. I understand that if you create a topic for each 
> sourceforge project, then you might need to update topics.conf at the 
> same time. This rises 2 concerns : 1) you need remote functions (via 
> SOAP) to update topics.conf 2) we need to define what privilege is 
> required to edit topics.conf ; listmaster privilege ? a new 
> authorization scenario ?
>
Well, currently I am using SOAP with authenticateRemoteAppAndRun so I
have just set up an application password for sourceforge itself.  This
is a luxury that I have since I am running something in front of sympa,
so to speak.  In general, it could be argued that a privileged owner and
above (listmaster) should have topics.conf access.  Limiting it to
listmaster isn't much of a step beyond leaving it to be edited manually
from CLI. A list may need to create a new topic for itself.  This can
lead to some mayhem, however, with a runaway number of topics.
 
> On the other hand why do you need to update topics.conf whenever a
> new project is created? Can't you just define high level topics in 
> topics.conf, each project being a subcategory. Example: topic 
> biocomputing would be defined in topics.conf, but 
> biocomputing/my_software would only be defined in the list
> configuration file.
> 
My current plan is to create a topic for each sourceforge project that
creates mailing lists.  So, each topic is named for a project and
'houses' the mailing lists for that project and that topic would need
to be checked for and possibly created during the creation of any new
list for a project.  I could try to instead set up topics based upon
the trove or 'categories' for projects, but there are too many
possibilities (topics by license, OS, target system, department,
software type).

You can define a subtopic in a list config?

> One feature you are probably missing but that you did not mention is
> a way to search all lists that belong to a given topic. This would
> require that Sympa either accepts an additional 'topic' parameter to
> the 'lists' SOAP function OR that the listType (returned by
> complexLists) is extended to provide the topics the lists belong to.
> With the later solution, you'd have to filter the lists in the
> sourceforge code. [...]
I think that feature is already in place.  The 'lists' method takes a
topic and subtopic arg.

-- 
Mark K