Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 05/03/2013 17:34, David Verdin a écrit :
> Dear all,
>
> With the upcoming install of Sympa 6.2 on our production server (next
> week), the subsequent beta phase and the load of mails we received from
> contributors / users / funders, I feel it is time to start putting
> together our thoughts about Sympa for the next couple of years.
>
>
>     Development plans
>
>
> Here are our plans of development. These are RENATER project, but you
> may have your own that can certainly find their place in the roadmap:
>
>
>         Features
>
>   * Sympa in SaaS mode. We want to allow full virtual hosting of a Sympa
>     service. That means a lot of evolutions for scalability concerns and
>     new robot deployment.
For myself, and probably for many other people, the term 'robot' refers 
to some kind of automatic web crawler, such as googlebot. Sympa seems to 
be the only place where this term refers (apparently) to an HTTP virtual 
host, and is not even used consistently, as the following terms seems to 
be used in the code:
- robot
- virtual robot
- domain
- virtual host

So please consider either dropping this historical terminology, in favor 
of something more mainstream, or at least ensure it is consistenty used 
everywhere in the code. It makes no sense to refers to 'virtual robot', 
if you don't have 'non-virtual robots' to make the difference useful.

> It will also require to make the largest part
>     of Sympa functionnalities accessible through the web and / or web
>     services (REST, SOAP). This is our next big step for Sympa 6.3.
>   * RFC 6729 <http://tools.ietf.org/html/rfc6729> implementation. This
>     RFC allows to add "Received by" headers with richer information,
>     such as "kept for moderation". This will greatly improve tracability
>     of message in mailing lists.
>   * RFC 5983 <http://tools.ietf.org/html/rfc5983> implementation. This
>     RFC deals with i18n addresses and mailing lists. I think Sympa
>     should implement it. I wonder whether Soji would have any advice
>     about this implementation, which look tricky...

>   * Potentially: changing our configuration file formalism to switch to
>     something more common, such as YAML <http://www.yaml.org>. We could
>     unify our configuration files and base them on CPAN modules instead
>     of our current home made parsers.
They are multiple level of unifications configuration.

1) distinguish file parsing from configuration handling
Look at the multiple load_something* functions used to read 
configurations files, each basically returning an hashref after checking 
its content. There is almost one function by configuration file...

Basically, we should aim to have just one parsing 
function/backend/whatever for every kind of currently used configuration 
format (xml, key/value pairs, etc...), and handle consistency checking 
separatly.

I didn't had a chance to look at what has already been done in 6.2 
branch, so the situation may have already improved.

2) merge the three different configurations locations constants

The default sympa sertup handle some part of the configuration under 
/etc, and some part undef $sympa_prefix/etc, resulting in 3 differents 
constants: CONFIG, WWSCONFIG and SYSCONFDIR, whereas a single one should 
be enough to identify each configuration file location.

3) reduce the different configuration formats to a unique one
YAML, JSON, XML, INI, whatever, I don't really care (excepted XML than 
sux), but a unique and consistent format would really make configuration 
easier.

Whereas 1 and 2 are quite transparent for end-users, 3 would introduce 
quite a drastic change. So I'd rather use a major version number change 
to make it more explicit: sympa 7.0.

The rest in another mail :)
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME