Minutes: MList call 28-Sep-05

*Attendees*
John-Paul Robinson, University of Alabama at Birmingham (stand-in chair)
Craig Hancock, University of Notre Dame
Paul Russell, University of Notre Dame
Serge Aumont, Comité Réseau des Universités (FR)
Olivier Salaün, Comité Réseau des Universités (FR)
Lisa Hogeboom, Internet2
Katherine Strojny, Internet2 (scribe)

*Action Items*

New:
[AI] {SteveO} How many downloads of the RPMs have occurred so far, from the Internet2 website? SteveO will  be asked to provide the stats. [AI] Investigate the issue of how to handle Perl modules that are required by Sympa that are outside the RPM but differ from the base Perl installation in Fedora Core. Discussion will be carried forward sympa-dev mailing list by {Craig & John-Paul & Jeff Abbott}. [AI] {John-Paul} posed the question of how Sympa can accommodate more flexible role definitions. He will describe the authorization enhancement and address it to the sympa-dev list.

Carry Over:
[AI] {SteveO} will work with {Craig} to post RPM/Fedora Core integration documentation on the WG's website. [AI] {Jill} make a formal announcement to the list informing members of the RPM/Fedora Core development completion. [AI] {Group} will evaluate and discuss possible future efforts in light of recent IETF developments. [AI] {Jill} will develop VO survey distribution list, and will follow up with NSF and DOE for possible VO survey candidates.

*Discussion*

The agenda included a review of feedback regarding Sympa RPM for Fedora Core, and discussion of issues relating to using Sympa as a data source. Discussion also touched on clarification of RPM objectives.

Intellectual Property Reminder:
The Internet2 intellectual property policy can be found here:
       http://members.internet2.edu/intellectualproperty.html

Sympa RPM Status, Feedback, and Objectives:

The group addressed the status of the Sympa RPM and discussed feedback received so far.

Is there a record of how many downloads of the RPMs we've seen so far? To what extent is the Internet2 community using it? [AI] {SteveO} may be able to provide these stats.

Olivier and Serge started testing the Sympa RPM on Fedora Core 3. Tests are not yet complete, but things have been working well so far. They will send comments to Craig.

What should the goals of testing be for the choice of small, medium, or large installation? The idea is to have any postmaster or mail administrator install on a Red Hat-based system without worrying about the nuances of configuring it for possible expansion or for performance. The small/medium/large installation corresponds to the projected needs of a small, medium, or large university. When SQLite comes into the stable distribution of Sympa, small institutions may want to take advantage of that and not worry about a relational database management system (RDBMS), whereas an RDBMS backend may be appropriate for large installation.

Is the size choice (small/medium/large) just linked to the backend or are there other issues? Currently, the concern is the database backend. However, in the future, it may be linked to other issues such as FCGI, whether the site uses the web interface, and different authentication configurations. Universities may ask for performance-related improvements relating to their core environment.

It was suggested that the RPM would benefit from the addition of a quick start document and a post-installation program to make the initial configuration file. Regarding post-installation decisions such as RDBMS choice, it was suggested that these decisions could be addressed by designing a configuration wizard or separate CGI form that would configure the initial sympa.conf. One reason to keep this separate from the main Sympa CGI involves permissions issues.

Is there a need for a relational database when you first install, for listmaster configuration and passwords? Currently, passwords and user preferences are always stored using an RDBMS. If you want to use the web interface, you need an RDBMS. Sympa version 5.2 introduces an SQLite database (as default), with one current drawback: SQLite doesn't have the "alter table" functionality needed to change table structure. One would have to export, remove, create new, and import a table to change its structure.

From a postmaster's point of view, what is expected/desired as far as Sympa mailing list administration? Should a postmaster have the versatility to both edit files and use web interface? Both. It depends on the site size and what the mailing list community will be doing with the tool.

The group discussed the objectives of the Sympa RPM, in relation to the extent that it is pre-configured out of the box versus left to the user to customize, since it can't be tailored to everyone's needs. It was expressed that one of the objectives of the RPM is to get Sympa in the hands of people interested in exploring it. While there are a number of tools available that are between generations, Sympa is a next-generation tool that already leverages enterprise data. General feedback on Sympa is that it's hard to start using. With the new RPM, the hope is that, as with Apache, someone may be able to install Sympa on the order of a day, rather than several days, in order to make decisions quickly and start planning production needs and customization requirements.

An install issue regarding Perl module dependencies launched a discussion of what to do in the general case where the RPM may require Perl modules not included in the base Red Hat installation. Jeff Abbott (Duke U.) had posted a question on sympa-users about the MIME-Base64 Perl module required by the Sympa RPM. This dependency cascades from the Sympa dependency on MIME-Words, which is used to encode and decode accented characters (RFC 1522) in international use. This leads to general question: How do we deal with Perl modules that are required by Sympa but differ from the base Red Hat installation? Ideally, installing the Sympa RPM would not involve side effects to the system. Discussion will be carried forward sympa-dev mailing list by {Craig & John-Paul & Jeff Abbott}.

Sympa as a Data Source:

John-Paul opened a discussion asking for thoughts and perspectives on Sympa as a data source. Sympa mailing lists can be used to define Virtual Organizations (VOs) that have attributes (open enrollment, moderated, etc.) Can that stored information be shared with participating VO applications? What we would expect from Sympa (as a data source) as far as a feature set? As a starting point, John-Paul posed two specific questions:

(1) What are the needs for potentially defining additional roles within Sympa? Is there a need to go beyond the roles currently defined? For instance, is there a need for configurable roles? [AI] {John-Paul} will describe the authorization enhancement in more detail and address it to the sympa-dev list.

(2) There is attribute information in Sympa that is viewable but perhaps not designed to be exported to other applications. Is it reasonable/possible for Sympa to export what policies are in place for a particular mailing list? The concept of "list families" is currently used, and in the near future, this concept can be used to create a kind (type) of list (e.g., open enrollment, moderated, archived). The value (name) of the list family will be easy to share, but it is not easy to ensure that the sharing applications both share the same meaning.

Discussion of old AI progress was postponed until the next call, which will be in two weeks (12-Oct-05).